Task:	Account management technology
Group:	neilb,sxw,ktd
Stage:	1

Description

A system for creating and managing user accounts is required. This will presumably interface to the Divisional Database, the LDAP infrastructure and the Kerberos infrastructure.

Report changes

2002-02-18

Biggest change is the renaming of the Assessment of Options to become the Final Decision section, and updates to those Final Decisions.
Revised some of the data in the data location section of the Issues
Progress updates.
Some rewording and grammatical changes.
Added changes and action section.

2002-02-28

Specified LDAP requirements (at end)
Some Interface details (at end)
Updated actions

2002-03-15

Moved Actions and Timescales to Stage1 progress document.
Added to the possible changes the fact that we'll maybe use the EUCS Kerberos realm for authentication.

2002-03-20

Updated the possible changes with the fact that we won't be using the EUCS Kerberos for stage 1.
Added clarification from the Authorisation task as to how account disabling will work, see the Disabling accounts issue

2002-05-11

Added clarification of how pseudo user acounts will work in the DICE world.

Initial report

Summary

The Account Management Procedures task, and others, need to be able to interface with the various database (InfDB), directory (LDAP) and authentication (Kerberos) services. This task will provide the interface(s)to these technologies.

Issues

Authorisation

1. It would be nice to be able to restrict certain classes of users to certain functions of the interfaces/tools. For example computing staff would have full access to create/disable/modify accounts, but we may want lab supervisors or ITO staff to be able to generate forgotten passwords, but nothing else.
   Simon thinks he may not have time to do this in time for deployment. See Timescales section.
2. If we are going to abstract the underlying technology from the user, can the database allow updates based on Kerberos credentials? Currently it is envisaged that users will have to authenticate themselves with their "admin" Kerberos principal, before being able to update LDAP/Kerberos data. If the database can't be kerberised, does that mean the user will have to enter their database username and passwd every time they call a tool that updates a database field? Perhaps an anonymous account could do it on their behalf.
3. Account information needs to be extracted to decide which class(es) a user belongs to. So we can confidently say user X is a member of 'lab supervisors', and therefore can change passwords. The buzzword for these classes is roles.

Pseudo accounts.

If all account information is to be held centrally, I assume this means pseudo accounts too. If we're going to have pseudo accounts in the new DICE world, how are we going to manage these? Will they need entries in any or all of the Database, LDAP, Kerberos? I assume so if all authentication and home directory information is somewhere in these data sources. If the username (Universal User Name) is mastered from the database, and if pseudo accounts are to exist in this namespace too, then presumably they must exist in the database.

Some feel for what pseudo accounts are used for. Currently there are 5 types of pseudo account have been identified:

1. Daemon 'run' accounts such as 'nobody', 'bindrun' and 'wwwrun' which provide a box in which to place daemons that would otherwise execute as root. They don't own files. Should only be accessing local files (if any), and therefore shouldn't need a Kerberos principal.
2. Other automated accounts like George's 'snmp' user that monitors switch logs and generates graphs for the web. These processes may need to write to remote mounted filesystems, and would need a Kerberos principal if we move to kerberised replacement for NFS.
3. Package accounts such as 'ssh' which provide home directory space to store package related code. It is hoped that these will go away, as we move towards more formal source management techniques such as RPM and CVS.
4. Group project accounts which have a shared filespace and shared access to allow collaborative work. eg CS3 practical groups, and have users using nsu to this user to allow work on the same files. These sort of accounts should be stopped and better collaborative working methods used, eg CVS.
5. Testing accounts such as 'inftest'. A user that computing staff could become to test the environment/system for a default user. ie without all their clever changes to the default setup so things work "better" for them. Might even be used to test future single sign-on to student mail for example. Though this may be a "pseudo" user, its account would be no different to a real user's account.

Update 11/5/2002
The above 5 cases boil down to just 2(ish) type of pseudo user:

1. The system account for processes only requiring local access to a particular machine. ie type 1 above.
2. Every other sort of account ie types 2 to 5 above, requiring some form of network access. Though it will be a policy decision to try and reduce the number of these accounts from their current prolification in the legacy world.

It was agreed at the DICE meeting of 30/4/2002, that the LCFG auth component would manage the creation of the local-to-machine system pseudo users. Their UIDs and GIDs will be in the sub-1000 range. Their usernames still need to be registered with the EUCS, so as to exclude that UUN from ever being used by a real person, though other departments may also choose to use that UUN internally. The database, LDAP, kerberos do not need to know about these accounts.

For all other types of pseudo users, the AMT and AMP tools/procedures would be used to manage/create the account. These users require a database and LDAP entry, some will also require a kerberos principal. They also require that their UUN be registered with the EUCS, in the case of a test user like 'inftest' this UUN would only be used by us. We may even ask the EUCS to give 'inftest' access to the student or staff mail services. Other users, like the shared group account 'cs1' or 'aisubmit', would just have their usernames registered with the EUCS's UUN exclusion list, so that no real user would be given these usernames. It would be OK though for other departments to use these usernames internally.

For users like 'cs1' or 'aisubmit' they would not need a kerberos principal (at least while we don't have a kerberised filesystem), and would probably have the primary group pseudo(10001). Test accounts like 'inftest' would require a kerberos principal and would probably be GID people(10000), so that to all intents and purposes they appear as real people.

A DICE only world?

Assuming we'll be providing client tools to run on some machine, can we assume this is a pure DICE machine, and not a hybrid DICE/legacy machine? If we're to cater for DICE and legacy machines, who's going to make sure that the language we write the tools in is available for each platform, eg C compilers, Perl interpreters?

This isn't really an issue now. We've decided that we're only catering for DICE machines. Users will have to log into a DICE machine to be able to carry out account management tasks. (apart from physically manipulating the home directories on the legacy file servers).

Home Directories.

Does the technology of how home directories are actually going to work fall into the remit of this task? I'm assuming it does not. Though information required to implement home directories may be stored via LDAP, etc, so we may/will have to provide the tools to access this information. We also need a way of propagating changes made to the users home directory information into the real automounter maps.

The data location(s)

We need to decide what data we need and where it will be mastered and stored. Currently we have agreed:

What	Master	Copy	Comment
username	DB	LDAP
Firstname	DB	LDAP	Can be combined with Lastname to give the GCOS.
Lastname	DB	LDAP
UID	DB	LDAP
GID	LDAP
Email	DB	LDAP	Ideally it would mastered from LDAP, so that users could change their own entry, but too much depends on the DB one.
Homedir	LDAP		eg /home/neilb
Home Partition	LDAP		eg u8 or twain9
Home Subdir	LDAP		Sub-directory within Home Partition eg staff/neilb or just s12345678.
Primary Roles	DB	LDAP	Not stored as a role in the DB, but used to generate the Primary roles stored in LDAP.
Secondary Roles	LDAP		"System" roles, eg beowulf-user.
Shell	LDAP
Passwd	Kerberos
Kerb Principal	Kerberos	LDAP
Active/Disabled flag	LDAP		This may not be the way to do this.
Disk quotas	LDAP		Or is this derived from role information
Print quota	LDAP		Or is this derived from role information

Keeping as much in the database gives us benefits of consistency checking, and possibly triggering automatic LDAP updates from changes in the database (harder to do, and perhaps not desirable the other way around). However not all changes, eg insertions and removals, would be automatic, but would require human intervention to propagate the change. An other option is that some sort of consistency checker runs independently checking that DB entries and their corresponding LDAP entries are in sync. If not, again some changes would be automatic, others would be flagged for mediation.

Currently, of the shared information between DB and LDAP, these fields would (or would not) be automatic.

Field	Auto update
Lastname	yes
Firstname	yes
Informal Name	yes
Email address	yes
Numeric UID	no
Username	no

As all the above is mastered in the DB, the automatic updates would be from the DB to LDAP. Insertions and deletions of whole records would be mediated.

Renamings

Kerberos and LDAP do not support change of usernames, so you can't just rename a user. You have to remove the old details and then add them back with the new username. The database can cope with renaming, as it is the Person@ field that's used as the key.

Disabling accounts

In the old world, some combination of starring out a passwd and/or changing the users shell to something like /etc/no_login, is used to stop a user from logging in. This allows the account to be reactivated easily should it have been mistakenly or temporarily disabled. How does this work in a Kerberos/LDAP world? It looks like a similar solution, a KRB5_KDB_DISALLOW_ALL_TIX flag is set in the KDC to stop the user getting any tickets, but this only affects kerberised services, so a similar passwd trick will also be needed. This could be a problem for the authorisation task. Perhaps some flag in LDAP would stop the PAM module from authorising that user.

The authorisation task has confirmed that some flag associated with the user will indicate whether the account is enabled or disabled, but the authorisation system won't use this directly. Instead it will modify the primary roles associated with the user, and its these roles (or lack of) that will restrict access to the system.

Current Situation

The 3 sites still use their existing underlying account generation scripts/procedures to physically create the home directories, passwd entries, etc, but some time ago it was decided to rationalise the username and uid name spaces. The database was seen as the central place to store this information. When accgen script is run with a list of users (or a class identifier), it interfaces with the DB to extract any already allocated username/uids. If they are not already allocated, then new ones are generated and fed back into the DB, so that other sites running accgen will use the now allocated username/uid. The output from accgen is then fed into the existing site's account generation scripts.

Goals

Options

• Consultation
  1. We provided what we think are the interfaces required and say "here you go"
  2. We liaise with the AMP (and other) tasks to find out what their (perceived) needs are, and provide an agreed interface.
• Level of abstraction
  1. Provide specific tools for each underlying technology.
  2. Try and hide the fact that its LDAP, DB, Kerberos behind the scenes. If we can abstract the interface, then any underlying change of technology would have less impact on the groups using the tools.
• Client or server interface and its nature
  1. The interface is provided by a client program run on remote machines.
  2. A API is provided by a library (e.g. perl module) used by client programs run on remote machines.
  3. The interface provided is only at the server end e.g. some daemon listening on a port or a CGI script/XML function running on a web server. Whoever wants to use it has to write their own client-side tool, communicating with the server in some well specified way.

Assessment of Options

Final Decision

Consultation

We will liase with other tasks to find out what they need, rather than second guess them.

Level of abstraction

All the information pertaining to a user's account that the Account Management Procedures task need to refer to and modify will be encapsulated in an Perl Account object. This object is already taking shape in the dice-accntmgr package, in the DICE CVS repository.

Interface

The interface will consist of the above Account object and a collection of Perl modules providing an AccountManager object which will retrieve and update Account objects. However, we will also provide at least one command line tool written using these modules as a proof of concept for the AMP task.

Pseudo Users

Pseudo users required for system operation, that only exist local to the machine will be created/managed by the LCFG auth component. All other types of pseudo users will be managed by the technology in this task, and by procedures in the AMP report.

Possible Changes

  - an overview of what subsequent changes could be made if, for
    example, anticipated technologies emerge.

Simon has mentioned that Kerberos and LDAP may merge in some way. So abstracting our interfaces would mean that we could plan for this change.

It's been noted that perhaps some form of web interface for users, to allow them to specify certain account details prior to their account being created could be implemented. See the Account Procedures Task, Possible Changes section for some more details. The significance to this task would be that we would provide some tool to be able to take this submitted data and create the account there and then when the user turns up. One issue may be the allocation of a UUN, it would be nice to have it on the web form, but do we want/can we allocate a UUN for a user that may not turn up (for whatever reason).

It's been suggested that there's a possibility that we may use the EUCS's Kerberos authentication realm for our authentication. This would mean that we either have to rely on the EUCS to create/modify kerberos credentials for users. Or some joint technology is developed that will allow the EUCS to devolve some of that management to us. The EUCS Kerberos will not be ready for next academic year, so this definitely won't happen for stage 1.

Review Timetable

  - a indication of when review of the revised strategy/policy might be
    needed.

Initial coding has begun, and the database access module is nearly complete. However, some decisions are still to be made about what information is to be stored and how before other modules (mainly LDAP) can proceed. We also still need to finalise the Account object, though we have agreed the data it will contain.

Actions and Timescales

Dependencies

• Account Management Procedures The interface we provide.
• File-system Maps How we feed information to them.
• Sun DICE integration Support for the tools on legacy systems.

LDAP Attributes

Key: PA - POSIX Account, FM - File System Map, AT - Authorisation Task

Note that the specifics of the FM and AT attributes are the responsibility of those tasks. For example the Authorisation task will probably decided that the primary and secondary roles are actually multivalued Distinguished Name references to the actual roles else where in the Directory Information Tree (DIT).

The Interface

The interface provided to the Account Management Procedures task, and others that need it is as follows. A Perl object representing a user account and another representing the Account Management System. The calling program requests an account object from the management system, then modifies the object as required, and then passes the object back to the management system to update the various data sources.

The dice-accntmgr RPM contains these objects. A typical invocation would look like this:

use strict;
use DICE::LocalAccntManager;
use DICE::Account;

my $manager = new DICE::LocalAcctManager;
my $account = $manager->retrieve( "sxw" );

$account->set( "homedir", "/home/sxw" );

$manager->update( $account );

It is not possible to create an account from scratch using this interface. The bare minimum requires that there is an entry in the Informatics Database, keyed on the user's Universal UserName (UUN), this is so that the retrieve above can locate the user. The only other public method of the LocalAccntManager is the delete() method. This will remove all system type information related to the user, provided the database agrees that the user should have left, but leave the database entries for the user intact.

Creation of new student accounts, with incomplete data in the database (ie missing UUN), will be done via another provided object that will be able to deduce the UUN from their matriculation number and will update the database programmatically. This is because the initial data feed of a new intake, or the ITO staff manually entering students, will probably not complete the UUN field, yet we will want to create system accounts for these students. In this case we will provide the unknown matric number, instead of the UUN, as fortunately the UUN for a student is the matric number with an 's' prepended.

Implementation Notes

Internally, the update method will be a 2 pass affair. The first pass is a check, making sure the datasource will accept any proposed updates. If all datasources are happy, then we actually try to update the data in those sources. If one (or more) are not happy, then no updating to any of the sources occurs (even if some were happy).

The authoritative flag will no longer be a boolean value, it may now be one of three values: <IsAuthoritative|NotAuthoritative|Informative>. This allows a datasource to volunteer information that it thinks is correct, but will allow a later authoritative datasource to override it.

To try and hide the authoritative flag of the Account object, from any AMP task calling Perl scripts, then $account->set("homedir","/home/neilb"); (note the missing authoritative parameter) will default to a sensible value for this flag. Probably IsAuthoritative

 : Deploy 

Please contact us with any comments or corrections. Unless explicitly stated otherwise, all material is copyright The University of Edinburgh