User registration

One of the first issues on a new host is to issue accounts for users. Surprisingly this is an area where operating system designers provide virtually no help. The tools provided by operating systems for this task are, at best, primitive and are

rarely suitable for the task without considerable modification. For small organi-zations, user registration is a relatively simple matter. Users can be registered at a centralized location by the system manager, and made available to all of the hosts in the network by some sharing mechanism, such as a login server, dis-tributed authentication service or by direct copying of the data. There are various mechanisms for doing this, and we shall return to them below.

For larger organizations, with many departments, user registration is much more complicated. The need for centralization is often in conflict with the need for delegation of responsibility. It is convenient for autonomous departments to be able to register their own users, but it is also important for all users to be registered under the umbrella of the organization, to ensure unique identities for the users and flexibility of access to different parts of the organization. What is needed is a solution which allows local system managers to be able to register new users in a global user database. User account administration has been discussed many times, see refs. [1, 299, 78, 190, 163, 195, 73, 216]. The special problems of each institution and work environment are reflected in these works.

PC server systems like NT and Netware have an apparent advantage in this respect. By forcing a particular administration model onto the hosts in a network, they can provide straightforward delegation of user registration to anyone with domain credentials. Registration of single users under NT can be performed remotely from a workstation, using the

net user username password /ADD /domain

command. While most Unix-like systems do not provide such a ready-made tool, many solutions have been created by third parties. The price one pays for such convenience is an implicittrust relationshipbetween the hosts. Assigning new user accounts is a security issue, thus to grant the right of a remote user to add new accounts requires us to trust the user with access to that facility.

It is rather sad that no acceptable, standardized user registration methods have been widely adopted. This must be regarded as one of the unsolved problems of system administration. Part of the problem is that the requirements of each organization are rather different. Many Unix-like systems provide shell scripts or user interfaces for installing new users, but most of these scripts are useless, because they follow a model of system layout which is inadequate for a network environment, or for an organization’s special needs.

5.2.1 Local and network accounts

Most organizations need a system for centralizing passwords, so that each user will have the same password on each host on the network. In fixed model computing environments such as NT or Novell Netware, where a login or domain server is used, this is a simple matter. In larger organizations with many departments or sub-domains it is more difficult [82, 306, 315].

Both Unix and NT support the creation of accounts locally on a single host, or

‘globally’ within a network domain. With a local account, a user has permission to use only the local host. With a network account, the user can use any host which belongs to a network domain. Local accounts are configured on the local

host itself. Unix registers local users by added them to the files/etc/passwdand /etc/shadow. In NT the Security Accounts Manager (SAM) is used to add local accounts to a given workstation.

For network accounts, Unix-like systems have widely adopted Sun Microsys-tems’ Network Information Service (NIS), formerly called Yellow Pages or simply YP, though this is likely to be superceded and replaced by the more widely accepted standard LDAP in the next few years. The NIS-plus service was later introduced to address a number of weaknesses in NIS, but this has not been widely adopted.

NIS is reasonably effective at sharing passwords, but it has security implications:

encrypted passwords are distributed in the old password format, clearly visible, making a mockery of shadow password files. NIS users have to be registered locally as users on the master NIS server; there is no provision for remote registration, or for delegation of responsibility. Variations on the NIS theme have been discussed in refs. [75, 252, 146]. NT uses its model of domain servers, rather like a NIS, but including a registration mechanism. A user in the SAM of a primary domain controller is registered within that domain and has an account on any host which subscribes to that domain. An approach to user accounts based on SQL databases was discussed in ref. [20].

An NT domain server involves not only shared databases but also shared administrative policies and shared security models. A host can subscribe to one or more domains and one domain can be associated with one another by a trust relationship. When one NT domain ‘trusts’ another, then accounts and groups defined in the trusted domain can be used in the trusting domain. NIS is indiscriminating in this respect. It is purely an authentication mechanism, implying no side-effects by the login procedure.

Other models of network computing include Kerberos and the Open Software Foundation’s Distributed Computing Environment (DCE). The former is a service brokering system with a common authentication service (see section 12.4.6).

The latter is a distributed user environment which can be used to provide a seamless world-wide distributed network domain. The DCE has been ported to both Unix and NT and requires a special login authentication after normal login to Unix/NT.

To summarize, rationalized user registration is a virtually unsupported problem in most operating systems. The needs of different organizations are varied and no successful solution to the problem has been devised and subsequently adopted as a standard. Networks are so common now that we have to think of the network first. Whether it happens today or tomorrow, at any given site, users will be moving around from host to host. They will need access to system resources wherever they are. It follows that they need distributed accounts. In creating a local solution, we have to bear in mind some basic constraints.

Principle 19 (Distributed accounts). Users move around from host to host, share data and collaborate. They need easy access to data and workstations all over an organization.

Standardizing usernames across all platforms simplifies both the logistics of user management and opens the way for cross-platform compatibility. User names

longer than eight characters can cause problems with Unix-like systems and FTP services. Users normally expect to be able to use the same password to log onto any host and have access to the same data, except for hosts with special purposes.

Suggestion 2 (Passwords). Give users a common username on all hosts, of no more than eight characters. Give them a common password on all hosts, unless there is a special reason not to do so. Some users never change their passwords unless forced to, and some users never even log in, so it is important to assign good passwords initially. Never assign a simple password and assume that it will be changed.

Perl scripts are excellent ways of making user installation scripts which are tailored to local needs. See ref. [211] for an excellent discussion of this on NT.

Interactive programs are almost useless since users are seldom installed one by one. At universities hundreds of students are registered at the same time. No system administrator would type in all the names by hand. More likely they would be input from some administrative list generated by the admissions department.

The format of that list is not a universal standard, so no off-the-shelf software package is going to help here.

Sites which run special environments, such as the Andrew File System (AFS), the Distributed Computing Environment (DCE), Athena or Kerberos, often require extra authentication servers and registration procedures [83, 315].

5.2.2 Unix accounts

To add a new user to a Unix-like host we have to:

• Find a unique username, user-id (uid) number and password for the new user.

• Update the system database of user accounts, e.g. add a line to the file /etc/passwdfor Unix (or on the centralized password server of a network) for the new user.

• Create a login directory (home directory) for the user.

• Choose a shell for the user (if appropriate).

• Copy some configuration files like .cshrc or .profileinto the new user’s directory, or update the system registry.

Because every site is different, user registration requires different tools and techniques in almost every case. For example: where should users’ home direc-tories be located? GNU/Linux has an adduser script which assumes that the user will be installed on the local machine under /home/user, but many users belong to a network and their disk space lies physically on a different host which is mounted by NFS.

Unix developers have created three different password file formats which increase the awkwardness of distributing passwords. The traditional password

file format is the following:

mark:Ax7Wc1Kd8ujo2:123:456:Mark Burgess:/home/mark:/bin/tcsh

The first field is a unique username (up to eight characters) for the user. The second is an encrypted form of the user’s password; then comes the user-id (a unique number which represents the user and is equivalent to the username) and the default group-id (a unique number which represents the default group of users to which this user belongs). The fifth field is the so-called GECOS field, which is usually just the full name of the user. On some systems, comma-separated entries may be given for full name, office, extension and home phone number. The sixth field is the home directory for the user (the root directory for the user’s private virtual machine). Finally the seventh field is the user’s default shell. This is the command interpreter which is started when the user logs in.

Newer Unix-like systems make use of shadow password files, which conceal the encrypted form of the password for ordinary users. The format of the password file is then the same as above, except that the second password field contains only an ‘x’, e.g.:

mark:x:123:456:Mark Burgess:/home/mark:/bin/tcsh There is then a corresponding line in/etc/shadowwith the form mark:Ax7Wc1Kd8ujo2:6445::::::

or with an MD5 password hash, on some systems. The shadow file is not readable by ordinary users. It contains many blank fields which are reserved for the special purpose of password aging and other expiry mechanisms. See the manual page for ‘shadow’ for a description of the fields. The only number present by default is the time at which the password was last changed, measured in the number of days since 1. Jan. 1970.

The third form of password file is used by the BSD 4.4 derived operating systems.

mark:Ax7Wc1Kd8ujo2:3232:25::0:0:Mark Burgess:/home/mark:/bin/tcsh It has extra fields, which are not normally used. These systems also have an opti-mization: in addition to the master password file base, they have a compiled binary database for rapid lookup. Administrators edit the file /etc/master.password and then run the pwd mkdb command to compile the database which is actu-ally used for lookups. This generates text and binary versions of the password database.

Entries might have to be added to the group membership file /etc/group, E-mail system and quota database, depending on local requirements.

5.2.3 Windows accounts

Single Windows accounts are added with the command net user username password /ADD /domain

or using the GUI. Windows does not provide any assistance for mass registration of users. The additional Resource Kit package contains tools which allow lists of users to be registered from a standard file format, with addusers.exe, but only at additional cost.

Windows users begin in the root directory by default. It is customary to create a\usersdirectory for home directories. Network users conventionally have their home directory on the domain server mapped to the drive H:. There is only a single choice of shell (command interpreter) for NT, so this is not specified in the user registration procedure. Several possibilities exist for creating user profiles and access policies, depending on the management model used.

5.2.4 Groups of users

Both Unix and NT allow users to belong to multiple groups. A group is an association of usernames which can be referred to collectively by a single name.

File and process permissions can be granted to a group of users. Groups are defined statically by the system administrator.

On Unix-like systems they are defined in the/etc/groupfile, like this:

users::100:user1,mark,user2,user3

The name of the group, in this case, is users, with group-id 100 and members user1, mark, user2 and user3. The second, empty field provides space for a password, but this facility is seldom used. A number of default groups are defined by the system, for instance

root::0:root other::1:

bin::2:root,bin,daemon

The names and numbers of system groups vary with different flavors of Unix. The root group has superuser privileges.

Unix groups can be created for users or for software which runs under a special user-id. In addition to the names listed in the group file, a group also accrues users from the default group membership in field four of /etc/passwd. Thus, if the group file had the groups:

users::100:

msql::36:

ftp::99:

www::500:www

www-data::501:www,toreo,mark,geirs,sigmunds,mysql,ulfu,magnem privwww::502:

and every user in/etc/passwdhad the default group 100, then theusersgroup would still contain every registered user on the system. By way of contrast, the group ftpcontains no members at all, and is to be used only by a process which the system assigns that group identity, whereas www-data contains a specific named list and no others as long as all users have the default group 100.

NT also allows the creation of groups. Groups are created by command, rather than by file editing, using:

net group groupname /ADD

Users may then be added with the syntax,

net group groupname username1 username2... /ADD

They can also be edited with the GUI on a local host. NT distinguishes global groups (consisting only of domain registered users) from local groups, which may also contain locally registered users. Some standard groups are defined by the system, e.g.

Administrators Users

Guest

The Administrators group has privileged access to the system.