The account creation process:
This section describes the steps involved in the account creation process. These are the steps followed by the user visible CGI interface. The differences between the CGI and CLI clients are documented throughout.
1) User Identification: The user is required to enter his/her first and last names, ssn, and birthday. This information is used to verify that the user exists in the PDB and to retrieve an RCPID which will be used for all future lookups. The user is also asked to choose an account type from a list of avaible types. This list is controlled through the "web_display" variable in each account type defined in the configuration file. The CLI tools do not offer a list of account types and only requires some limited amounts of information about the user. The CGI tool is more stringent about authorization information because it allows end users to create accounts automatically, and without supervision.
2) Check Roles: Each account type can require 0 or more roles. These roles are either real PDB roles or secondary HERD roles. The client does not differentiate between HERD roles and PDB roles, however the sysadmin configuring the client must understand that they are different. New HERD roles may be requested from the RATS administrator, and may be added to a person in the PDB through a number of individuals privileged to use the herd tool. PDB roles are relatively fixed and generally describe large groups. For each account type there can be three types of roles defined. The first type is a list of roles in which ALL roles must be satisfied, the second type are those from which AT LEAST ONE role must be satisfied, and the last is a list of roles the user can not have if he/she is to qualify for this account type These lists are defined in the configuration file as req_role->all, req_role->some, and req_role->none for each account type. The CLI interface does not check roles.
3) Check Roster: For each account type, there can be 0 or more classes. This is for classacct support. The classes are identified by their official University registration index numbers, term, and year . All this information may be obtained from the schedule of classes for each semester. Again, these can specified in three lists, one which requires the user to be in all the listed classes (roster->all), one for one or more classes (roster->some), and an exclusion list (roster->none). We expect that the "some" list will be more useful as it allows multiple recitations to be combined in one requirement. Also the roster requierments can be set either for a hole class or any section of the class. The CLI tool does not check roster.
4) Check Campus: For each account type there can be 0 or more campuses required. These campus can be again declared in the "all" (campus->all), "some" (campus->some), or "none" (campus->none) method. Currently only the three major campuses are supported ("NB", "NK", "CM") and they are supported for students only. We hope to implement some better granularity for version 2 as well as support for geographic restrictions for employees. Note that the campuses are derived from the school codes and their aproximate mapping to the phisical locations. The CLI tool does not check campuses.
5) Check major/school: For each account type there can be 0 or more majors/schools required. They use the previously mentioned all/some/none format for control. They are the three digit number found in the schedule of classes available in every semester. These of course only apply to the STUDENT role.
6) Username Generation: If the user identified at step 1 does not already have a username allocated, 8 choices are generated out their first and last names. These choices are first checked against the PDB to ensure that they don't already exist. The user is presented with these choices but he/she can also pick a different username. The chosen username is checked against the PDB and for IID-like properties (1-4 alpha followed by numbers). If the username is not acceptable the question will be posed again. Otherwise the username entry is created in the PDB.
7) Password: Depending on the authentication type for each account
type the user may or may not be prompted for a password. For example if
the account already exists no password operations will be performed. If
enigma passwords are used, then the user will not be prompted for a password
as well and the appropriate entry will be added the password field (read
bellow about principles). If the authentication type is kerberos or crypt
the user will be prompted for a new password. The password is checked
for length and content (three character classes) and set. However
if the user already has a kerberos principle set for this realm that no
password change takes place. The CLI tool will only set the kerberos principle
if the appropriate command line option was used. The principle for
both enigma and kerberos methods can be build out of the right number of
"#"'s (as defined in the config file) and an actual principle which can
be either the IID or the username as configured for each account type.
There is also the ability to set the password field to
any string you want. For example you can set the authtype to 'string=BECOME'
and the word become will be placed in the password field in the shadow
file.
8) Passwd entry: If this is a new account then a password entry is created with the various attributes defined for that account type. If the account already exists, and the GID field does not match that of the account being currently created, it is saved for later (see step 8).
9) Group additions: If additional groups are configured for this account type, then the user is added to these groups in the group file. Note that if a primary GID was saved from step 7 due to an already existing account, the user is also added to group represented by this GID.
10) Home directory: If a home directory is needed, it is now created. The permissions and ownerships are also set as configured.
11) Set home quota: The quota is set for the home directory of the user. If the user already exists, then the old quota is read and the new one is added to the existing one.
12) Set mail quota: If a maildir is declared then the appropriate quota is set.
13) Set quotas elsewhere: If so configured, a quota of 1 is also set on all the other existing filesystem, except that where the home directory resides.
14) Copy startup files: If a list of files to be copied and their targets is configured for this account type, they are copied into the user's home directory. This only gets done for new accounts.
15) Link startup files: If a list of files to be linked and their targets is configured for this account type, they are linked into the user's home directory. This only gets done for new accounts
16) Admin Scripts: For each account type, the system administrator can define two scripts to be run at the end of the account creation process. The first script will be run only if this was a new account. The second script will be run even if the account was previously created. Note that if both scripts are run then the "first time" script will be run first.
17) Set email in PDB: If the account type being created is configured
to set an email address in the PDB for a given ROLE, then RATS will first
check to see if an address was already set for that role and user.
If no address was set then the RATS will go ahead and set one. If
an address was already set for this ROLE then the user will be given a
choice to select between the existing address and the one currently
being created. The ROLE for which the email will be set
is defined in the config file for each account type and not bound to the
requiered ROLES for the account type, as to allow for multiple requierments
without non deterministic behaviours.
The account removal process
These are the steps followed by the removal option in ratsadmin. Steps
marked as (A) are followed
if only one account type is removed, those marked with (B) are used
if the whole account is being
nuked.
1) Check if account exists
2) Get list of accounts for user.
3A) Check if the account type to be removed is on the list
4) Get list of groups for the user
5A) Determine which groups should be removed, depending on the account
type and groups used
by other account types
6) Remove user from all the appropriate groups.
7A) Determine if this is the users last account. If so, follow final removal algorithm.
8A) Remove user from account type
8B) Remove user from all account types.
9) Run admin defined scripts for account type removals.
10) Adjust mail quotas per account type definitions.
11A) Determine if a primary GID change is need it and perform it
11B) Archive user as configured in the config file
12B) Remove user's home directory
13B) Remove user's email address from all PDB roles if the email address matches their address on this machine.
14) Adjust home directory quotas
15B) Remove user from passwd/shadow.
16B) Run final global remove script
Various internal considerations
The following are various other internals which may be of interest to sysadmins.
1) UID Generation: By default, RATS will examine the password file and
generate the next highest UID and allocate it to the new account, unless
an UID was already reserved for that user in which case the reserved UID
is returned. The UID/username pair will also be added to a reservation
file. This allows for fast turnaround of accounts and backup integrity,
because the pairs are not automatically removed from the reservations file.
This file should be expired periodically by comparing it to the PDB for
valid usernames. A tool to do this will eventually be avaible. UID's
can also be generated by requesting the UID of the user being created from
a different host. If the username does not exist on the remote machine
and the remote machine allows UID reservation, that a entry will be made
in the remote machine's reservation file and a UID returned. That
same UID will be return for any other future requests from other hosts
and also will be use on the remote host when and if an account is create
there. This
also holds true
for GID generation.
3) Group file maintenance: Because group entries should not be longer
then 1024 characters, RATS makes sure to break up groups into multiples
if needed. This is done by creating a new group with the following format
<groupname>-<ext><number>, where <groupname> is the original
group name, <ext> is an extension token defined in the config file,
and <number> is some increasing number representing the number of such
sub groups. All the entries will share a GID which will keep the system
happy. These groups are rechecked and trimmed every time a group
update occurs for that particular group. Though not used by any tools
as of the writing of this document, there
are API calls to support creation, deletion, and maintenance of the
groups, including GID synchronization and reservation.
4) File Locking: Files that need to be locked are locked
with both lock files and flock's on the lock files. On a very busy server
the flock may or may not give you some headaches. This is the main
reason why Version 2 supports a
DataBase interface.