RATS: Specialized Account HandlingRATS can be used to handle a number of the anomolous account types found at Rutgers. In order to make account creation for strange types of accounts more standardized, we have come up with processes for the following types of accounts. Most of these processes revolve around "program people" which are basically fake people int he PDB with a role of program. Each ICI and RCI cluster on each campus will be issued their own program person to use for their clusters. If a departmental cluster find themselves in need of one, they should contact rats_support@email.
Short Term Transient Guests: These are basically people who are going to be here for a short period of time and are not going to be back at any predictable interval. The canonical example are the PALS program where we do not know how long they will be here, if they are coming back, and if they will have the same vital stats if/when they do. The process here is that whoever is responsible for the STTGs gets a prgram person in the PDB and is told the appropriate IID. They then set up an account type that does not display on the web that uses username for the kerberos principle rather than IID. Then you can feed your users into ratsut to reserve usernames for them. Then you use ratsadmin to create that account type for your list of users. The sysadmin (or other entitiy if you can get someone else to take ownership of a program person for it) is responsible for keeping track of who has what username in case of abuse of account privileges. We suggest that the usernames have a pattern that will not collide with the main username space. For example, PALS uses PALS<palsnumber>. This looks like an IID which is ok since IIDs are no longer valid usernames for anyone. Note that there is no kerbshelling these people since we cannot authenticate them. You can only shut down there account and make them come in so you can fix it with them present (probshell).
Long Term Guest: These are people who are going to be associated with the university for an extended duration. A good example is the turf school. Turf school participants are here for several two week stretches over the course of two years, and we can gather appropriate demographic information on them. LTGs without a valid social security number can be accomodated with the add-a-person tool, so don't let a lack of SSN keep you from taking advantage of this type of account. Long term guests should be added through the add-a-person tool with a role of GUEST, and a herd that will allow them on your system. You can then tell the LTG to simply use the web interface to create their account, or run them through ratsadmin. At some point this should become essentially a real time process. At the moment it is a 24 hour turnaround.
New Arrival Employees: These are the folks who show up for a job, and wind up twiddling their thumbs for two weeks until payroll feeds them in to the PDB if you don't do something about it. The appropriate way to handle this is by runing them through the add-a-person tool using staff or faculty as is appropriate. Then let them use the web interface or run them through using ratsadmin. You should give them an expiration date so that they stop being listed as fac/staff if they never push through from payroll. There is a word of warning here though. If they do not have a real SSN, allocating a fake one can cause a problem when payroll pushes them to the PDB as payroll will issue them a real meaningful SSN. The PDB will then have two entries for them, and the account will be tied to the orphaned identity. We are currently trying to figurre out the best way of addressing this problem.
Grad/Undergrrad not in PDB: These are students who are arriving early, or for some reason haven't been pushed into the PDB. In this case you should run them through the add-a-person tool as a student with an appropriate expiration date which will be erased when the registrar pushes the data through to the PDB. If they need a fake SSN, they should have one issued by the registrar. This does not mean that the add-a-person is meaningless as you will likely not see that updated infor for the better part of a week. This process hsould become realtime in the near future, at the moment there is a 24 hour turnaround.
Departmental Accounts: Departmental accounts come in two varieties. One is become accounts, and the other is a normal account with a shared password. Accounts with shared passwords are created in the same manner as short term transient guests with a few key differences. Responsibility for the bookeeping is restricted to the cluster the account is on. That means that they should be created using the IID of the "program person" for the cluster, and the sysadmin of the cluster should keep track of who requested the account so they can point the people in the gray sedans at them when the time comes. Become accounts should follow the procedure for become accounts.
Become Accounts: Become accounts should configure an account type in the config file that is not web displayable that does all the proper become settings (see the config file documents, it includes specifying the username as a principle rather than iid). You should create the appropriate become group id on the machine (doesn't matter if you do it before or after). You then use ratsut to reserve a username using the IID of the cluster's "program person". Then you run that username through ratsadmin to create the account. Then you use the group hacking tool (vigr.cgi) to add the become accounts group to the appropriate users.