Types and levels of accounts

This note outlines the main issues involved in opening and closing different types of user account, apart from opening student accounts, which we have already dealt with. It is written from a User Services viewpoint and so is quiet about the mechanisms required to implement the suggestions. Although it is expressed in a fairly definite fashion, this is only for the sake of brevity, and these proposals are as yet tentative and provisional.

Levels of access

Accounts can be in the following different states, giving different sorts of access:

  • New: account created but not yet opened; access only to the password creation page
  • Open:web access only; mail not accepted, no access to home directory; can change password using the standard password-changing page
  • Active: this is the normal state, with access to web, email, ftp, home directory, printing and classrooms
  • Active+shell: if user has been approved for shell access they can log in with ssh to a compute-server
  • De-activated: reduced to web access only; email is rejected unless forwarding is in place; data and existing mailbox archived. “Web access” means access to restricted web pages. Not all de-activated accounts will have access to the same restricted pages. Two that they will all need access to is the forwarding and request for closure pages, but there will be others.
  • Closed: web access removed, password disabled, forwarding cancelled, data and existing mailbox deleted

Web access for open and de-activated accounts needs to be more clearly defined. All we mean so far is that the username and password can be used for web authentication. We will need to tell web-authors how to distinguish accounts in these levels from active accounts.

Closing student accounts

What we need is a more staggered process of deactivating student accounts. Without thinking too much about the mechanics, here are the states which might be required:

The deactivation (and closure) will follow these stages:

  1. Until date A (eg end of graduation week) accounts remain active, with shell access if approved. During this period users cannot request de-activation.
  2. BetweendateAand dateB (say three weeks before start of new session) students marked as finished can ask to have their accounts de-activated, but not closed.
  3. On date B students marked as finished are notified that their accounts will be de-activated on dateC (say 10 days after start of new session). They can ask to have their accounts closed. They can also notify us of any mistake or change of plan.
  4. On dateC the accounts of those notified in stage3 but who have not reported a mistake or change of plan (and whose record is still marked as finished) will be de-activated, or closed if the student requests it.

Shell access: Accounts of those who are continuing at the University will remain active, usually with a change of status (eg underg to postg, postg to staff or ext). If their status has changed they will need to re-apply for shell access if they want it after dateC.

Forwarding: Among the web facilities available to those with de-activated accounts should be pages enabling them to request closure and set up and amend their own forwarding arrangements.

Opening staff accounts

New staff may need active accounts before they arrive in St Andrews, giving them access to their home directory (eg via ftp), email and web pages. Others may need only open accounts, for access to web pages. This is a possible sequence:

  1. When a staff number is allocated the username should also be created
  2. At some point the username, mail alias and initial password can be given to the staff member, with instructions to open the account by using the password creation page. This can be done either in person at the Helpdesk or by email to an email address vouched for by the user’s department
  3. The user may not wish to open the account before arriving, but they may still profit from knowing their email address in advance. (Staff users should be encouraged to use their mail alias, which should be given in the directory in preference to their username.)
  4. Is some additional layer of credentials needed before activating the account (comparable with the students producing their acceptance letter)? If not, then there need be no distinction between opening and activating for staff accounts.

Closing staff accounts

Need to decide at what point staff accounts should cease to be active. At present there is no uniform policy, and possibly there cannot be any completely uniform line.

  1. At any time after the end of contract the user or the user’s former department can ask to have the account de-activated or closed.
  2. At some point not too long after the end of contract the account will be de-activated, if it is currently active
  3. If the account is needed for an extended period after the end of contract it must be converted to external

Functional email accounts

These will be set up with a named owner. Only the owner will be able to change the password. Functional accounts can be used in a number of ways:

  • Only the owner reads the mail
  • The owner arranges for the mail to be forwarded to the personal mailboxes of colleagues
  • The owner enters the password in the POP client on a colleague’s computer and saves it
  • The owner shares the password with one or more colleagues

All except the first option have drawbacks which will need to be explained to users setting up functional accounts.

Ownership can be transferred – this must be done before an owner leaves. Functional accounts will be de-activated if the current owner’s account is de-activated or closed.

Functional email accounts are only for email. There is no classroom access and no access to protected web pages. We should probably permit ftp access to the home directory (where IMAP mail folders will be stored).

The owner will administer the shared account using web forms, authenticating with their own personal username and password.

These accounts (or their aliases) need to be included in the directory services in some way.

Shared web space accounts

These will work in more or less the same way as the current secondary accounts, except we will need web-based forms for administering them instead of the secauth command.

External accounts

The account will be created and username and initial password sent or given to the user. Contact details will be supplied by the sponsor. The user will then open and activate the account by creating a password. As with staff accounts we might decide we need an additional layer of security between opening and activating the account. There may be some restricted web pages to which external users need access.

Closing external accounts should be simpler than for staff accounts. Arguably, there is no need for the deactivated status, because once the account is no longer needed it can be closed altogether.

Conference accounts

At present these are completely impersonal, and the passwords are given out by the sponsor, and we get a list of signatures after the event. Conference accounts currently have all functions, but they really only need classroom access, printing and home directory.

Conference accounts will in future give access to ResNet and the wireless network. We need to know during the lifetime of the account who it belongs to, and how they can be contacted. For ResNet, do they need email (for “connection ready” messages)? This will need to be considered as part of the ResNet procedure for these accounts. The delivery address for all these accounts could be a single account owned by the conference organizer.

Walk-in accounts

These are ready-to use accounts available from the Helpdesk, issued in return for proof of identity and a signature. They give classroom access only, no printing or disk space – they use the temporary disk space on the PCs. The Helpdesk changes the password on these accounts when they are handed back by the users, so that they are ready for the next walker-in.

1