Version 1.2 • 11 July 2016
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. Between date A and date B (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 date C (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 date C the accounts of those notified in stage 3 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 date C.
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).
2
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.
3