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 two types of roles defined. The first type is a list of roles in which ALL roles must be satisfied and the second type are those from which AT LEAST ONE role must be satisfied. These lists are defined in the configuration file as req_role->all and req_role->some 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 two lists, one which requires the user to be in all the listed classes (roster->all) and one for one or more classes (roster->some). We expect that the "some" list will be more useful as it allows multiple recitations to be combined in one requirement. 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) or "some" (campus->some) 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.. 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 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 account removal process
These are the steps followed by the removal option in ratsadmin
1) Check if account exists
2) Archive user as configured in the config file
3) Remove user from all groups
4) Remove user's home directory
5) Remove user's email address from all PDB roles if the email address matches their address on this machine.
6) Remove user from passwd/shadow.
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.
2) Encryption: All the RATS parts (clients, client daemons, main_server) share an API. However each call and response is encrypted using triple CBC_DES. The encryption is always performed using the client's keys. For example if host A connects to host B, then host A will encrypt its message with its own key and host B will reply encrypting with the key of A. Because encrypted strings can contain NULL's and newlines and any other various legitimate characters, the communications code first calculates the length of the message to be sent, prints the length to the network as a net long, followed by the actual message. The receiving side reads the length and then that many bytes for the message itself. Note that the server side of rats limits the transmitted data to a fixed maximum length as well. This is currently set at 800 bytes.
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.
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. In version 2 we hope
to implement a system that will both reduce file locking problems and permit
easier account maintenance on systems with large user bases.