• Overview
• Creating Accounts
• Users.db Meta-data File
• Setting/Changing Passwords
• Converting Undergrad Accounts to Grad Accounts
• Propagating Accounts to Windows Domain Controller and Samba
• Propagating Accounts to the LDAP Server
• Propagating Accounts to other servers
• Mail server account policy
• Printer Billing
• Account Policies
• Expiring and Deleting Accounts
• Moving Forward
  

Account maintenance scripts:

• must be run from hyper
• must be run as root (except for the 'passwd' command)
• are located in /opt/sysadmin/common/passwd/
• more detailed documentation available in 00ReadMe (eg. contents of files in that directory)

There are 4 ways to create a PHAS account:

addusr: This is the main account creation script for creating all but undergraduate accounts.

• It prompts for various bits of information about the new account.
• Answers will affect: uid/gid, home directory, print quota, expiration date, whether PHAS email is enabled, PHAS email distribution list inclusion, etc. etc.
• Information not reflected in /etc/passwd|shadow files is stored in the users.db meta-data file (see notes below).

register: This script will create an account appropriate for an undergraduate student.

• IF you specify it is for a "registered" student, it will check the list of current students and will extract the first and last name based on the student#.
• See SIS download notes.
• If you specify "not registered" then you can enter whatever student# and name you like.
• NOTE: This is seldom used since most undergrads use the Kiosks (see next section).  Exceptions include visiting undergrads.
  

webreg: This script is used to create undergraduate student accounts via the Computer Lab Kiosks in Hennings 203 and 205 (marked "REGISTER HERE").

• URL for Clab registration form is: https://secure.phas.ubc.ca/clabreg/
• Students are first asked to agree to the UBC Appropriate Use Policy.
• They are then authenticated via their CWL usernames.
• The program checks various things: eg. are they a registered student, does an account already exist for this student# or username, etc. etc.
• If all checks are passed a request is made to create an account (same username as CWL).
• Requests are transmitted to hyper via the request file: /opt/sysadmin/common/www/webreg.requests
• Perl script to update the request file: www:/usr/local/php/bin/send_webreg.pl
• The request file is processed via 'webreg' which is run by crontab on hyper every 5 minutes between 6am and 6pm.
• The log file for the webreg script is webreg.log
• The password is displayed for 1 minute on the Kiosk screen. (It is no longer emailed to <username>@interchange.ubc.ca.)

add_many: Script to create multiple accounts from a file of usernames and other information.

/opt/sysadmin/common/passwd/users.db:
This file conntains one record for each account with the following fields:

username:Full Name:Account:Category:ExpDate:Account#:student#:Comment

• "Account" is used to associate grad students/postdocs/visitors with a supervisor/patron - both for printer billing and expiration purposes.
• "Category" will determine if/which email list the account should be added to - and whether an expiry date is required.  (See the Mail List documentation for details on email lists.)
  
• "Account#" is only used if the printer billing is different from the supervisor/patron.

Choose a category:
 System  = account needed for system software
 Ugrad   = an undergraduate student
 One of -> Adj-Assoc, Faculty, Grads, Others, Postdocs, Staff
         = dept. member (ie. Admin staff will enter into database) and will be 
	   	on corresponding email list
 Misc    = generic account for course (eg. physNNN) or group (eg. mbelab) 
		- expiry date required
 Visitor = default - expiry date required

Enter account - "?" to see list [Unknown]: ?
Valid Accounts are:
Affleck        Ahlborn        Ampel          Astr310        Barth          
Behr           Berciu         Bonn           Brewer         Bryman         
Celler         CGay           Chemistry      Choptuik       Clab           
Clark          Co-op          Damascelli     Dept           Dilling 
etc.

passwd:

• location: /usr/local/bin/passwd (copy of /opt/sysadmin/common/passwd/passwd)
  
• calls /usr/bin/passwd.orig
  
• passwords are modified immediately on: localhost (hyper), local Samba password, phasPDC, LDAP Server
• see the notes on other Unix host account propagation
  

initpw:

• re-computes the initial password for Kiosk-generated accounts (webreg)
• used when they have forgotten their initial password and have not already re-set it
• computes a 10-char. password;  passwords generated before Sep2012 will have only the first 8 chars.
  

Converting Undergrad Accounts to Grad Accounts

Please see: This document.

Samba (SMB) Password

• Passwords are propagated to the Samba Password file: /etc/samba/smbpasswd via the passwd command.

PHASPDC (Windows domain controller) and Samba Password

• Accounts are created on the Windows Domain Controller (PDC) at the time a password is set.
• If no password is set, then the account will not exist in the Windows Domain.
• Communication with PHASPDC is via ssh and Windows Powershell scripts:

  • NewUser.ps1 (to add an account)
  • ChangeUserPwd.ps1 (to change the password)
    
• Users are not allowed to change their passwords.
• $category and $gcos (full name) fields are obtained from the file users.db file
• The $category field is used to map to Windows groups via the COMMENT field:
  • If Category = Adj-Assoc|Faculty|Others|Postdocs|Visitor, Comment is set to "Faculty".
  • If Category = Staff, Comment is set to "Staff".
  • If Category = Grads, Comment is set to "Grads".
  • If Category = Ugrad|Misc, Comment is set to "Ugrad".
  • Otherwise, the account is NOT PROPAGATED to the Windows Domain (ie. excludes System accounts).
    
  The upshot is that the following Windows groups are used: Faculty Staff Grads Ugrads

• Accounts are created on the LDAP Server at the time a password is set.
• If no password is set, then the account will not exist on the LDAP Server.
• Unlike for PDC, LDAP accounts are created for all accounts, including System accounts.
• Command to create an account on the LDAP server:
         $mesg = $ldap->add("uid=$me,".$CONF{"dn_suffix"},
        attrs => [
        "objectclass"   => $CONF{"obj_class"},
        "uidNumber"     => $uid,
        "gidNumber"     => $gid,
        "cn"            => $gecos,
        "gecos"         => $gecos,
        "sn"            => $lastname,
        "givenName"     => $firstname,
        "homeDirectory" => $homedir,
        "loginShell"    => $shell,
        "mail"          => $mail,
        "userPassword"  => $pass
        ]);

  

Accounts are propagated to other unix platforms by rsyncing to the following files from hyper:

• /etc/passwd
• /etc/group
• /etc/shadow
• /etc/samba/smbpasswd

• builds appropriate passwd/shadow/group files for different platforms, eg. RHEL, Solaris, Ubuntu
  
• Note: the smbpasswd file is modified directly by the passwd command
  
• invokes (via ssh) an rsync script on each server (/etc/pgs_get) to "pull" the 4 files from falcon
  
• current servers are: romulan mail mail2 mail3 stingray students zorok cups
• logins are not allowed on these server (except for those usernames above the "splitz" record)
  

When modifying /etc/group by hand: It is necessary to force the propagation via the command:/opt/sysadmin/common/passwd/prop_pgs group 

The workstations in the computer lab (Hennings 203) now authenticate users via LDAP.

As of 2009-08-27 we no longer automatically enable email for all users.

• addusr creates home directories with default .dovecot.sieve files on the mail server for all users.
• However it only enables email for accounts that have Category of Faculty, Staff, Postdocs, Others, Adj-Assoc or Grads (ie. "everyone@phas").
  (It will also add the new address to the events@phas list for these accounts.)
• It disables email for other accounts simply by setting up forwarding to "disabled@phas.ubc.ca" (which will return "error:5.2.1:550 User Email Account Disabled").
• To enable email after the fact, simply remove the .forward file.
  
• To create a home directory on the mail server for an account that doesn't have one for some reason (historic?) , on mail run: /opt/sysadmin/passwd/make_mailhome {username} ENABLE

The Accounts field in the users.db file is used to assign usernames to a supervisor or group for printer billing as well as account expiration. The data in the users.db file is uploaded daily to MySQL database sysadmin.phas_users. Run via crontab on falcon:

# at 5:30AM every day: upload /opt/sysadmin/common/passwd/users.db to the dbase03:sysadmin.phas_users table
30 5 * * * /opt/sysadmin/common/passwd/phas_users_dbase03.pl > /dev/null 2>&1

# at 7AM on the first day of every month: save non-cash printing balances and zero them out
0 7 1 * * /opt/sysadmin/printing/monthend.pl > /dev/null 2>&1

A random set of policies:

• mail is not enabled for new users unless they are part of "everyone@phas.ubc.ca"
• new users who are part of "everyone" are automatically subscribed to "events@phas.ubc.ca"
• "everyone" accounts expire after 3 months of being removed from department directory or grad student database
  
• undergrad accounts expire at the end of September if they are not registered in a PHAS course or program
• we have no disk quotas currently
• undergraduate users pay for printing ($.10/page) - otherwise it is charged to a speedchart (departmental by default for new grad students) ($.075/page)
  

Account Monitoring:

• a daily script checks all records in the users.db file: mail:/opt/sysadmin/passwd/check_ids.pl
• actually reads records from MySQL database: sysadmin.phas_users (uploaded daily from users.db file via omega cronjob)
• sends notification email to acctadmin@phas.ubc.ca
• checks following categories against directory.department database: => Faculty, Staff, Postdocs, Adj-Assoc, Others
  • mail:/opt/sysadmin/passwd/check_grads.pl does this for the Grads category and gradstudents.students
    
  • when an account is no longer "current" in one of the databases the following is done manually:
    
    • users.db is updated to change the category to "Xwhatever" and set an expiry date >=3 months from current date
      
    • the email address is removed from the corresponding email list
      
• checks expiry dates for the following categories: Ugrad, Visitor, XFaculty/XStaff/XGrads/etc
• doesn't do anything about System and Astrolab accounts
• should be checking expiry dates on Misc accounts, but the list became overwhelming - 188 accounts at last count ...  :-(
  

Procedure for expired Visitor, XFaculty/XStaff/XGrads/etc accounts:

• an expiration notification email is sent by:
  
  1. moving (or copying then deleting) the relevant user.db records to the file mail:/opt/sysadmin/usermaint/exp.yymmdd
     NOTE:often a supervisor email address (third field) requires correcting.
     
  2. mail:/opt/sysadmin/usermaint/send.msg.both is run to notify both user and supervisor/patron
• depending on response, new expiry dates may be set (aka the negotiation phase)
  
  Sample email to send to people who request a new expiry date:
  You have asked to have <expired-user>'s account be kept active even though it has expired. Our policy is that users have three months after they leave until their accounts expire and they are given ample notice to make arrangements ahead of time. Unless there is a very good reason to keep this account active, we want to delete it. In general, "still need to collaborate" is *not* a valid reason to keep an account active - I'm sure you closely collaborate with many people who do not have PHAS accounts.
  
  Our main concern is that these accounts can pose an increased security risk. For instance, if they become inactive, they may be hacked and no one will notice. It also is harder to notice unusual remote logins.
  
  Please let me know if you have good reason to let <expired-user> keep his account.
  
  Regards,
• if no response after a couple of weeks, or confirmed okay to delete account:
  
  • in users.db a new expiry date is manually set - typically at least a month ahead
  • a comment is added at the end of the record:  "DELETE"
  • the password is disabled by editing hyper:/etc/shadow and prefixing the password with:  "**disabled yymmdd**"
    NOTE: Since we started authenticating via the LDAP server, this method of disabling accounts doesn't work for all services, eg. hyper, computer labs, secure site (soon).
• when the "Deletion Date" (2nd expiration) comes around, the account is deleted via rmusr command (see below)
  

Email aliases will be kept for a maximum of three (3) months after the "Deletion Date"

Procedure for expired Ugrad accounts:

• by default all Undergrad accounts have expiration dates set to Sept. 30 of the following academic year
• in October: the current PHAS class-list and program files are checked and new expiry dates set for current students
• accounts for non-current students are disabled and have expiry dates reset to sometime in January
  
• in January: any accounts that haven't been re-enabled are deleted
• scripts to do all this are in: hyper:/opt/sysadmin/common/password/ugrad_accts/
• for all the gory details of Ugrad account maintenance, please see the 00README file in that directory
  
• disclaimer: it is not pretty, however typically ~300 accounts get deleted every year (and there are very few "oops")
  

Tools in /opt/sysadmin/common/passwd/:

• rmusr: This is an interactive program to remove an account from all servers.  It does the following:
  
  • delete entry in pykota database
  • delete entry in /etc/group
  • remove home directory
  • delete entry in users.db file
  • delete from PDC
  • delete from LDAP server
  • delete entries in /etc/passwd, /etc/shadow and /etc/samba/smbpasswd
  • should probably be checking /etc/aliases as well ...
    
• ugrad_accts directory: Scripts to maintain undergraduate accounts are located here. See the 00README file in that directory.
• rm_many_feed_usernames_only: delete many accounts from a list of usernames in a file; experience resulted in the long script name ...
  

• get all servers authenticating via LDAP
  
  • Done: hyper, computer labs
  • Still to do: mail/beta, samba on alpha and omega, delta (pykota? pine? login server?), secure/gamma
    
• since getting the PDC to use LDAP might be difficult, we plan to continue to propagate accounts/passwords via ssh from a unix host (web server)
  
  • now using Powershell script to create accounts and modify passwords on the PDC
  • issues with special chars. (except single quote) and password longer than 14 char. have been resolved - although new issues keep appearing, eg. LDAP server strips spaces at beginning (and end?) of password
• we want web forms for adding and removing accounts
  
• we want  a web form for setting passwords (direct all users to web instead of hyper)
  
  • new password-strength algorithm? or use existing one?
    

NewUser.ps1

ChnageUserPwd.ps1