Before anyone can use your system they must have an account. This chapter examines user accounts and the responsibilities of the Systems Administrators with regards to accounts. By the end of this chapter you should

§         be aware of the process involved in creating and removing user accounts,

§         be familiar with the configuration files that UNIX uses to store information about accounts,

§         know what information you must have to create an account,

§         understand the implications of choosing particular usernames, user ids and passwords,

§         be aware of special accounts including the root account and the implications of using the root account,

§         have been introduced to a number of public domain tools that help with account management.

A UNIX account is a collection of logical characteristics that specify who the user is, what the user is allowed to do and where the user is allowed to do it. These characteristics include a

§         login (or user) name,

§         password,

§         numeric user identifier or UID,

§         a default numeric group identifier or GID,
Many accounts belong to more than one group but all accounts have one default group.

§         home directory,

§         login shell,

§         possibly a mail alias,

§         mail file, and

§         collection of startup files.

Login names

The account of every user is assigned a unique login (or user) name. The username uniquely identifies the account for people. The operating system uses the user identifier number (UID) to uniquely identify an account. The translation between UID and the username is carried out reading the /etc/passwd file (/etc/passwd is introduced below).

Login name format

On a small system, the format of login names is generally not a problem since with a small user population it is unlikely that there will be duplicates. However on a large site with hundreds or thousands of users and multiple computers, assigning a login name can be a major problem. With a larger number of users it is likely that you may get a number of people with names like David Jones, Darren Jones.

The following is a set of guidelines. They are by no means hard and fast rules but using some or all of them can make life easier for yourself as the Systems Administrator, or for your users.

§         unique
This means usernames should be unique not only on the local machine but also across different machines at the same site. A login name should identify the same person and only one person on every machine on the site. This can be very hard to achieve at a site with a large user population especially if different machines have different administrators.

The reason for this guideline is that under certain circumstances it is possible for people with the same username to access accounts with the same username on different machines.

§         up to 8 characters
UNIX will ignore or disallow login names that are longer. Dependent on which platform you are using.

§         Lowercase
Numbers and upper case letters can be used. Login names that are all upper case should be avoided as some versions of UNIX can assume this to mean your terminal doesn't recognise lower case letters and every piece of text subsequently sent to your display is in uppercase.

§         Easy to remember
A random sequence of letters and numbers is hard to remember and so the user will be continually have to ask the Systems Administrator "what's my username?"

§         No nicknames
A username will probably be part of an email address. The username will be one method by which other users identify who is on the system. Not all the users may know the nicknames of certain individuals.

§         A fixed format
There should be a specified system for creating a username. Some combination of first name, last name and initials is usually the best. Setting a policy allows you to automate the procedure of adding new users. It also makes it easy for other users to work out what the username for a person might be.

Passwords

An account's password is the key that lets someone in to use the account. A password should be a secret collection of characters known only by the owner of the account.

Poor choice of passwords is the single biggest security hole on any multi-user computer system. As a Systems Administrator you should follow a strict set of guidelines for passwords (after all if someone can break the root account's password, your system is going bye, bye). In addition you should promote the use of these guidelines amongst your users.

Password guidelines

An example set of password guidelines might include

§         use combinations of upper and lower case characters, numbers and punctuation characters,

§         don't use random combinations of characters if they break the following two rules,

§         be easy to remember,
If a user forgets their password they can't use the system and guess whom they come and see. Also the user SHOULD NOT have to write their password down.

§         be quick to type,
One of the easiest and most used methods for breaking into a system is simply watching someone type in their password. It is harder to do if the password is typed in quickly.

§         a password should be at least 6 characters long,
The shorter a password is the easier it is to break. Some systems will not allow passwords shorter than a specified length.

§         a password should not be any longer than 8 to 10 characters,
Most systems will look as if they are accepting longer passwords but they simply ignore the extra characters. The actual size is system specific but between eight and ten characters is generally the limit.

§         do not use words from ANY language,
Passwords that are words can be cracked (you'll see how later).

§         do not use combinations of just words and numbers,
Passwords like hello1 are just as easy to crack as hello.

§         use combinations of words separated by punctuation characters or acronyms of uncommon phrases/song lines,
They should be easy to remember but hard to crack. e.g. b1gsh1p

§         change passwords regularly,
Not too often that you forget which password is currently set.

§         never reuse passwords.

The UID

Every account on a UNIX system has a unique user or login name that is used by users to identify that account. The operating system does not use this name to identify the account. Instead each account must be assigned a unique user identifier number (UID) when it is created. The UID is used by the operating system to identify the account.

UID guidelines

In choosing a UID for a new user there are a number of considerations to take into account including

§         choose a UID number between 100 and 32767 (or 60000),
Numbers between 0 and 99 are reserved by some systems for use by system accounts. Different systems will have different possible maximum values for UID numbers. Around 32000 and 64000 are common upper limits.

§         UIDs for a user should be the same across machines,
Some network systems (e.g. NFS) require that users have the same UID across all machines in the network. Otherwise they will not work properly.

§         you may not want to reuse a number.
Not a hard and fast rule. Every file is owned by a particular user id. Problems arise where a user has left and a new user has been assigned the UID of the old user. What happens when you restore from backups some files that were created by the old user? The file thinks the user with a particular UID owns it. The new user will now own those files even though the username has changed.

Home directories

Every user must be assigned a home directory. When the user logs in it is this home directory that becomes the current directory. Typically all user home directories are stored under the one directory. Many modern systems use the directory /home. Older versions used /usr/users. The names of home directories will match the username for the account.

For example, a user jonesd would have the home directory /home/jonesd

In some instances it might be decided to further divide users by placing users from different categories into different sub-directories.

For example, all staff accounts may go under /home/staff while students are placed under /home/students. These separate directories may even be on separate partitions.

Login shell

Every user account has a login shell. A login shell is simply the program that is executed every time the user logs in. Normally it is one of the standard user shells such as Bourne, csh, bash etc. However it can be any executable program.

One common method used to disable an account is to change the login shell to the program /bin/false. When someone logs into such an account /bin/false is executed and the login: prompt reappears.

Dot files

A number of commands, including vi, the mail system and a variety of shells, can be customised using dot files. A dot file is usually placed into a user's home directory and has a filename that starts with a . (dot). This files are examined when the command is first executed and modifies how it behaves.

Dot files are also known as rc files. As you should've found out by doing one of the exercises from the previous chapter rc is short for "run command" and is a left over from an earlier operating system.

Commands and their dot files

Table 9.1 summarises the dot files for a number of commands. The FAQs for the newsgroup comp.unix.questions has others.

Table 9.1
Dot files

Shell dot files

These shell dot files, particularly those executed when a shell is first executed, are responsible for

§         setting up command aliases,
Some shells (e.g. bash) allow the creation of aliases for various commands. A common command alias for old MS-DOS people is dir, usually set to mean the same as ls -l.

§         setting values for shell variables like PATH and TERM.

Skeleton directories

Normally all new users are given the same startup files. Rather than create the same files from scratch all the time, copies are usually kept in a directory called a skeleton directory. This means when you create a new account you can simply copy the startup files from the skeleton directory into the user's home directory.

The standard skeleton directory is /etc/skel . It should be remembered that the files in the skeleton directory are dot files and will not show up if you simply use ls /etc/skel. You will have to use the -a switch for ls to see dot files.

Exercises

The mail file

When someone sends mail to a user that mail message has to be stored somewhere so that it can be read. Under UNIX each user is assigned a mail file. All user mail files are placed in the same directory. When a new mail message arrives it is appended onto the end of the user's mail file.

The location of this directory can change depending on the operating system being used. Common locations are

§         /usr/spool/mail,

§         /var/spool/mail,
This is the standard Linux location.

§         /usr/mail

§         /var/mail.

All mail in the one location

On some sites it is common for users to have accounts on a number of different computers. It is easier if all the mail for a particular user goes to the one location. This means that a user will choose one machine as their mail machine and want all their email forwarded to their account on that machine.

There are at least two ways by which mail can be forwarded

§         the user can create a .forward file in their home directory (see Table 7.1),  or

§         the administrator can create an alias.

Mail aliases

If you send an e-mail message that cannot be delivered (e.g. you use the wrong address) typically the mail message will be forwarded to the postmaster of your machine. There is usually no account called postmaster (though recent distributions of Linux do). postmaster is a mail alias.

When the mail delivery program gets mail for postmaster it will not be able to find a matching username. Instead it will look up a specific file, usually /etc/aliases or /etc/mail/names (Linux uses /etc/aliases). This file will typically have an entry like

  postmaster: root

This tells the delivery program that anything addressed postmaster should actually be delivered to the user root.

Site aliases

Some companies will have a set policy for e-mail aliases for all staff. This means that when you add a new user you also have to update the aliases file.

For example

The Central Queensland University has aliases set up for all staff. An e-mail with an address using the format Initial.Surname@cqu.edu.au will be delivered to that staff member's real mail address.

In my case the alias is d.jones@cqu.edu.au. The main on-campus mail host has an aliases file that translates this alias into my actual e-mail address jonesd@jasper.cqu.edu.au.

Linux mail

The following exercise requires that you have mail delivery working on your system.  You can test whether or not email is working on your system by starting one of the provided email programs (e.g. elm) and send yourself an email message.  You do this by using only your username as the address (no @).  If it isn't working, refer to the documentation from RedHat on how to get email functioning.

Exercises

Most of the characteristics of an account mentioned above are stored in two or three configuration files. All these files are text files, each account has a one-line entry in the file with each line divided into a number of fields using colons.

Table 9.2. lists the configuration files examined and their purpose. Not all systems will have the /etc/shadow file. By default Linux doesn't however it is possible to install the shadow password system. On some platforms the shadow file will exist but its filename will be different.

 

File	Purpose
/etc/passwd	the password file, holds most of an account characteristics including username, UID, GID, GCOS information, login shell, home directory and in some cases the password
/etc/shadow	the shadow password file, a more secure mechanism for holding the password, common on more modern systems
/etc/group	the group file, holds characteristics about a system's groups including group name, GID and group members

Table 9.2
Account configuration files

/etc/passwd

/etc/passwd is the main account configuration file. Table 9.3 summarises each of the fields in the /etc/passwd file. On some systems the encrypted password will not be in the passwd file but will be in a shadow file.

* not on systems with a shadow password file

Table 9.3
/etc/passwd

Exercises

Every user on the system must be able to read the /etc/passwd file. This is because many of the programs and commands a user executes must access the information in the file. For example, when you execute the command ls -l command part of what the command must do is translate the UID of the file's owner into a username. The only place that information is stored is in the /etc/passwd file.

This is a problem

Since everyone can read the /etc/passwd file they can also read the encrypted password.

The problem isn't that someone might be able to decrypt the password. The method used to encrypt the passwords is supposedly a one way encryption algorithm. You aren't supposed to be able to decrypt the passwords.

Password matching

The way to break into a UNIX system is to obtain a dictionary of words and encrypt the whole dictionary. You then compare the encrypted words from the dictionary with the encrypted passwords. If you find a match you know what the password is.

Studies have shown that with a carefully chosen dictionary, between 10-20% of passwords can be cracked on any machine. Later in this chapter you'll be shown a program that can be used by the Systems Administrator to test users' passwords.

An even greater problem is the increasing speed of computers. One modern super computer is capable of performing 424,400 encryptions a second. This means that all six-character passwords can be discovered in two days and all seven-character passwords within four months.

The solution

The solution to this problem is to not store the encrypted password in the /etc/passwd file. Instead it should be kept in another file that only the root user can read. Remember the passwd program is setuid root.

This other file in which the password is stored is usually referred to as the shadow password file. It can be stored in one of a number of different locations depending on the version of UNIX you are using. A common location, and the one used by the Linux shadow password suite, is /etc/shadow.

Shadow file format

Typically the shadow file consists of one line per user containing the encrypted password and some additional information including

§         username,

§         the date the password was last changed,

§         minimum number of days before the password can be changed again,

§         maximum number of days before the password must be changed,

§         number of days until age warning is sent to user,

§         number of days of inactivity before account should be removed,

§         absolute date on which the password will expire.

The additional information is used to implement password aging. This will be discussed later in the security chapter.

A group is a logical collection of users. Users with similar needs or characteristics are usually placed into groups. A group is a collection of user accounts that can be given special permissions. Groups are often used to restrict access to certain files and programs to everyone but those within a certain collection of users.

/etc/group

The /etc/group file maintains a list of the current groups for the system and the users that belong to each group. The fields in the /etc/group file include

§         the group name,
A unique name for the group.

§         an encrypted password (this is rarely used today) ,

§         the numeric group identifier or GID, and

§         the list of usernames of the group members separated by commas.

For example

On the Central Queensland University UNIX machine jasper only certain users are allowed to have full Internet access. All these users belong to the group called angels. Any program that provides Internet access has as the group owner the group angels and is owned by root. Only members of the angels group or the root user can execute these files.

The default group

Every user is the member of at least one group sometimes referred to as the default group. The default group is specified by the GID specified in the user's entry in the /etc/passwd file.

Since the default group is specified in /etc/passwd it is not necessary for the username to be added to the /etc/group file for the default group.

Other groups

A user can in fact be a member of several groups. Any extra groups the user is a member of are specified by entries in the /etc/group file.

It is not necessary to have an entry in the /etc/group file for the default group. However if the user belongs to any other groups they must be added to the /etc/group file.

All UNIX systems come with a number of special accounts. These accounts already exist and are there for a specific purpose. Typically these accounts will all have UIDs that are less than 100 and are used to perform a variety of administrative duties. Table 9.4. lists some of the special accounts that may exist on a machine.

 

Table 9.4
Special accounts

root

The root user, also known as the super user is probably the most important account on a UNIX system. This account is not subject to the normal restrictions placed on standard accounts. It is used by the Systems Administrator to perform administrative tasks that can't be performed by a normal account.

Restricted actions

Some of the actions for which you'd use the root account include

§         creating and modifying user accounts,

§         shutting the system down,

§         configuring hardware devices like network interfaces and printers,

§         changing the ownership of files,

§         setting and changing quotas and priorities, and

§         setting the name of a machine.

Be careful

You should always be careful when logged in as root. When logged in as root you must know what every command you type is going to do. Remember the root account is not subject to the normal restrictions of other accounts. If you execute a command as root it will be done, whether it deletes all the files on  your system or not.

Adding a user is a fairly mechanical task that is usually automated either through shell scripts or on many modern systems with a GUI based program. However it is still important that the Systems Administrator be aware of the steps involved in creating a new account.  If you know how it works you can fix any problems which occur. 

The steps to create a user include

§         adding an entry for the new user to the /etc/passwd file,

§         setting an initial password,

§         adding an entry to the /etc/group file,

§         creating the user's home directory,

§         creating the user's mail file or setting a mail alias,

§         creating any startup files required for the user,

§         testing that the addition has worked, and

§         possibly sending an introductory message to the user.

Other considerations

This chapter talks about account management which includes the mechanics of adding a new account. User management is something entirely different. When adding a new account, user management tasks that are required include

§         making the user aware of the site's policies regarding computer use,

§         getting the user to sign an "acceptable use" form,

§         letting the user know where and how they can find information about their system, and

§         possibly showing the user how to work the system.

These tasks are covered in the following chapter.

Pre-requisite Information

Before creating a new user there is a range of information that you must know including

§         the username format being used at your site,
Are you using djones jonesdd david jones or perhaps you're using student or employee numbers for usernames.

§         the user's name and other person information,
Phone number, are they a computing person, someone from sales?

§         where the user's home directory will be,

§         will this user need a mail file on this machine or should there be an alias set up,

§         startup shell,

§         startup files,

§         UID and GID.
Again there should be some site wide standard for this.

Adding an /etc/passwd entry

For every new user, an entry has to be added to the /etc/passwd file. There are a variety of methods by which this is accomplished including

§         using an editor,
This is a method that is often used. However it can be unsafe and it is generally not a good idea to use it.

§         the command vipw, or
Some systems (usually BSD based) provide this command. vipw invokes an editor so the Systems Administrator can edit the passwd file safely. The command performs some additional steps that ensures that the editing is performed consistently. Some distributions of Linux supply vipw.

§         a dedicated adduser program.
Many systems, Linux included, provide a program (the name will change from system to system) that accepts a number of command-line parameters and then proceeds to perform many of the steps involved in creating a new account. The Linux command is called adduser

The initial password

NEVER LEAVE THE PASSWORD FIELD BLANK.

If you are not going to set a password for a user put a * in the password field of /etc/passwd or the /etc/shadow file. On most systems, the * character is considered an invalid password and it prevents anyone from using that account.

If a password is to be set for the account then the passwd command must be used. The user should be forced to immediately change any password set by the Systems Administrator

/etc/group entry

While not strictly necessary, the /etc/group file should be modified to include the user's login name in their default group. Also if the user is to be a member of any other group they must have an entry in the /etc/group file.

Editing the /etc/group file with an editor should be safe.

The home directory

Not only must the home directory be created but the permissions also have to be set correctly so that the user can access the directory.

The permissions of a home directory should be set such that

§         the user should be the owner of the home directory,

§         the group owner of the directory should be the default group that the user belongs to,

§         at the very least, the owner of the directory should have rwx permissions, and

§         the group and other permissions should be set as restrictively as possible.

The startup files

Once the home directory is created the startup files can be copied in or created. Again you should remember that this will be done as the root user and so root will own the files. You must remember to change the ownership.

For example

The following is example set of commands that will perform these tasks.

mkdir home_directory
cp -pr /etc/skel/.[a-zA-Z]* home_directory
chown -R login_name home_directory
chgrp -R group_name home_directory
chmod -R 700 home_directory

Setting up mail

A new user will either

§         want to read their mail on this machine, or

§         want to read their mail on another machine.

The user's choice controls how you configure the user's mail.

A mail file

If the user is going to read their mail on this machine then you must create them a mail file. The mail file must go in a standard directory (usually /var/spool/mail under Linux). As with home directories it is important that the ownership and the permissions of a mail file be set correctly. The requirements are

§         the user must be able to read and write the file,
After all, the user must be able to read and delete mail messages.

§         the group owner of the mail file should be the group mail and the group should be able to read and write to the file,
The programs that deliver mail are owned by the group mail. These programs must be able to write to the file to deliver the user's mail.

§         no-one else should have any access to the file,
No-one wants anyone else peeking at their private mail.

Mail aliases and forwards

If the user's main mail account is on another machine, any mail that is sent to this machine should be forwarded to the appropriate machine. There are two methods

§         a mail alias, or

§         a file ~/.forward

Both methods achieve the same result. The main difference is that the user can change the .forward file if they wish to. They can't modify a central alias.

Testing an account

Once the account is created, at least in some instances, you will want to test the account creation to make sure that it has worked.  There are at least two methods you can use

§         login as the user

§         use the su command.

The su command

The su command is used to change from one user account to another. To a certain extent it acts like logging in as the other user. The standard format is su username.

[david@beldin david]$ su
Password:

Time to become the root user.  su without any parameter lets you become the root user, as long as you know the password.  In the following the id command is used to prove that I really have become the root user.  You'll also notice that the prompt displayed by the shell has changed as well.  In particular notice the # character, commonly used to indicate a shell with root permission.

[root@beldin david]# id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel)
[root@beldin david]# pwd
/home/david

Another point to notice is that when you don't use the "–" argument for su all that has changed is user and group ids.  The current directory doesn't change.

[root@beldin david]# cd /
[root@beldin /]# pwd
/
[root@beldin /]# su david
[david@beldin /]$ pwd
/
[david@beldin /]$ exit

However, when you do use the "–" argument of the su command, it simulates a full login.  This means that any startup files are executed and that the current directory becomes the home directory of the user account you "are becoming".  This is equivalent to logging in as the user.

[root@beldin /]# su – david
[david@beldin david]$ pwd
/home/david

If you run su as a normal user you will have to enter the password of the user you are trying to become. If you don't specify a username you will become the root user (if you know the password).

The "–" switch

The su command is used to change from one user to another. By default, su david will change your UID and GID to that of the user david (if you know the password) but won't change much else. Using the - switch of su it is possible to simulate a full login including execution of the new user's startup scripts and changing to their home directory.

su as root

If you use the su command as the root user you do not have to enter the new user's password. su will immediately change you to the new user. su especially with the - switch is useful for testing a new account.

Exercises

Inform the user

Lastly you should inform the user of their account details. Included in this should be some indication of where they can get assistance and some pointers on where to find more documentation.

Exercises

Deleting an account involves reversing the steps carried out when the account was created. It is a destructive process and whenever something destructive is performed, care must always be taken. The steps that might be carried out include

§         disabling the account,

§         backing up and removing the associated files

§         setting up mail forwards.

Situations under which you may wish to remove an account include

§         as punishment for a user who has broken the rules, or
In this situation you may only want to disable the account rather than remove it completely.

§         an employee has left.

Disabling an account

Disabling an account ensures that no-one can login but doesn't delete the contents of the account. This is a minimal requirement for removing an account. There are two methods for achieving this

§         change the login shell, or
Setting the login shell to /bin/false will prevent logins. However it may still be possible for the user to receive mail through the account using POP mail programs like Eudora.

§         change the password.

The * character is considered by the password system to indicate an illegal password. One method for disabling an account is to insert a * character into the password field. If you want to re-enable the account (with the same password) simply remove the *.

Another method is to simply remove the entry from the /etc/passwd and /etc/shadow files all together.

Backing up

It is possible that this user may have some files that need to be used by other people. So back everything up, just in case.

Remove the user's files

All the files owned by the account should be removed from whereever they are in the file hierarchy. It is unlikely for a user to own files that are located outside of their home directory (except for the mail file). However it is a good idea to search for them. Another use for the find command.

Mail for old users

On some systems, even if you delete the user's mail file, mail for that user can still accumulate on the system. If you delete an account entirely by removing it from the password field, any mail for that account will bounce.

In most cases, a user who has left will want their mail forwarded onto a new account. One solution is to create a mail alias for the user that points to their new address.

As mentioned previously there is little point in adding users manually.  It is a simple task which can be quite easily automated.  This section looks at some of the tools you can use to automate this task.

There are at least three goals a Systems Administrator will want to achieve with adding users

§         make it as simple as possible

§         automate the addition of large numbers of users

§         delegate the task of adding users to someone else

The following sections will show you the tools which will allow you to achieve these goals.

If you’ve completed exercise 9.9 you should by now be aware of what a straight forward, but time consuming, task creating a new user account is.  Creating an account manually might be okay for one or two accounts but adding 100 this way would get quite annoying.  Luckily there are a number of tools which make this process quite simple.

useradd

useradd is an executable program which significantly reduces the complexity of adding a new user.  A solution to the previous exercise using useradd looks like this

useradd –c "David Jones" david

useradd will automatically create the home directory and mail file, copy files from skeleton directories and a number of other tasks.  Refer to the useradd man page for more information.

userdel and usermod

userdel is the companion command to useradd and as the name suggests it deletes or removes a user account from the system.  usermod allows a Systems Administrator to modify the details of an existing user account.

Graphical Tools

RedHat Linux provides a number of tools with graphical user interfaces to help both the Systems Administrator and the normal user.  Tools such as userinfo and userpasswd allow normal users to modify their user accounts.  RedHat also provides a command called control-panel which provides a graphical user interface for a number of Systems Administration related tasks including user management.

control-panel is in fact just a simple interface to run a number of other programs which actually perform the tasks.  For example, to perform the necessary user management tasks control-panel will run the command usercfg.  Diagram 9.1 provides examples of the interface provided by the usercfg command.

 

Diagram 9.1
usercfg interface

Throughout this text we will be referring to a public domain Systems Administration tool called Webmin (http://www.webmin.com).  Webmin provides a Web-based interface to a number of standard Systems Administration tasks including user management.  Diagram 9.2 displays the Webmin web page for creating a new user account.  The major advantage of a tool like Webmin is that it uses the Web.  This means it has all the benefits of the Web including the fact that it can be used from anywhere that you have a Web connection.

 

 

Diagram 9.2
Webmin user creation interface

Exercises

Tools with a graphical user interface are nice and simple for creating one or two users.  However, when you must create hundreds of user accounts, they are a pain.  In situations like this you must make use of a scripting language to automate the process.

The process of creating a user account can be divided into the following steps

§         gathering the appropriate information,

§         deciding on policy for usernames, passwords etc,

§         creating the accounts,

§         performing any additional special steps.

The steps in this process are fairly general purpose and could apply in any situation requiring the creation of a large number of user accounts, regardless of the operating system.

Gathering the information

The first part of this chapter described the type of information that is required in order to create a UNIX user account.  When automating the large scale creation of user accounts this information is generally provided in an electronic format.  Often this information will be extracted from a database and converted into the appropriate format.

For example, creating Web accounts for students studying 85321 was done by extracting student numbers, names and email addresses from the Oracle database used by Central Queensland University.

Policy

Gathering the raw information is not sufficient.  Policy must be developed which specifies rules such as username format, location of home directories, which groups users will belong to and other information discussed earlier in the chapter.

There are no hard and fast rules for this policy.  It is a case of applying whatever works best for your particular situation.

For example

CQ-PAN (http://cq-pan.cqu.edu.au) is a system managed mainly by CQU computing students.  CQ-PAN provides accounts for students for a variety of reasons.  During its history it has used two username formats

§         ba format
The first username format, based on that used by Freenet system, was ba005 ba103 ba321

§         name format
This was later changed to something a little more personal, firstnameLastInitialNumber.  e.g.  davidj1 carolyg1

Creating the accounts

Once you know what format the user information will be in and what formats you wish to follow for user accounts, you can start creating the accounts.  Generally this will use the following steps

§         read the information from the provided data file

§         convert it into the format specified in the site policy

§         use the UNIX account creation commands to create the accounts

Additional steps

Simply creating the accounts using the steps introduced above is usually not all that has to be done.  Most sites may include additional steps in the account creation process such as

§         sending an initial, welcoming email message,
Such an email can serve a number of purposes, including informing the new users of their rights and responsibilities.  It is important that users be made aware as soon as possible of what they can and can't do and what support they can expect from the Systems Administration team.

§         creating email aliases or other site specific steps.

Changing passwords without interaction

Quite a few years ago there was a common problem that had to be overcome in order to automate the account creation process.  This problem was how to set the new user's password without human intervention.  Remember, when creating hundreds of accounts it is essential to remove all human interaction.

Given that this is such a common problem for UNIX systems, there are now a number of solutions to this problem.  RedHat Linux comes with a number of solutions including the commands chpasswd, newusers and mkpasswd.

mkpasswd is an example of an Expect (http://expect.nist.gov/) script. Expect is a program that helps to automate interactive applications such as passwd and others including telnet ftp etc.  This allows you to write scripts to automate processes which normally require human input.

For example

In the pre-Web days (1992), satellite weather photos were made available via FTP from a computer at James Cook University.  These image files were stored using a standard filename policy which indicated which date and time the images were taken.  If you wanted to view the latest weather image you had to manually ftp to the James Cook computer, download the latest image and then view it on your machine.

Manually ftping the files was not a large task, only 5 or 6 separate commands, however if you were doing this five times a day it got quite repetitive.  Expect provides a mechanism by which a script could be written to automate this process.

Systems Administrators are highly paid, technical staff.  A business does not want Systems Administrators wasting their time performing mundane, low-level, repetitive tasks.  Where possible a Systems Administrator should delegate responsibility for low-level tasks to other staff.  In this section we examine one approach using the sudo command.

Many of the menial tasks, like creating users and performing backups, require the access which the root account provides. This means that these tasks can't be allocated to junior members of staff without giving them access to everything else on the system.  In most cases you don't want to do this.

There is another problem with the root account.  If you have a number of trusted Systems Administrators the root account often becomes a group account.  The problem with this is that since everyone knows the root password there is now way by which you can know who is doing what as root.  There is no accountability.  While this may not be a problem on your individual system on commercial systems it is essential to be able to track what everyone does.

sudo

A solution to these problems is the sudo command. sudo (http://www.courtesan.com/courtesan/products/sudo/) is not a standard UNIX command but a widely available public domain tool. It comes standard on most Linux distributions.  It does not appear to be included with RedHat 5.0.  You can find a copy of sudo on the 85321 Web site/CD-ROM under the Resource Materials section for week 5.

sudo allows you to allocate certain users the ability to run programs as root without giving them access to everything. For example, you might decide that the office secretary can run the adduser script, or an operator might be allowed to execute the backup script.

sudo also provides a solution to the accountability problem. sudo logs every command people perform while using it.  This means that rather than using the root account as a group account, you can provide all your Systems Administrators with sudo access.  When they perform their tasks with sudo, what they do will be recorded.

For example

To execute a command as root using sudo you login to your "normal" user account and then type sudo followed by the command you wish to execute.  The following example shows what happens when you can and can't executable a particular command using sudo.

[david@mc:~]$ sudo ls
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these two things:

        #1) Respect the privacy of others.
        #2) Think before you type.

 85321.students                     archive
[david@mc:~]$ sudo cat
Sorry, user david is not allowed to execute "/bin/cat" as root on mc.

If the sudoers file is configured to allow you to execute this command on the current machine, you will be prompted for your normal password. You'll only be asked for the password once every five minutes.

/etc/sudoers

The sudo configuration file is usually /etc/sudoers or in some instances /usr/local/etc/sudoers. sudoers is a text file with lines of the following format

username  hostname=command

An example sudoers file might look like this

root  ALL=ALL
david ALL=ALL
bob   cq-pan=/usr/local/bin/backup
jo    ALL=/usr/local/bin/adduser

In this example the root account and the user david are allowed to execute all commands on all machines. The user bob can execute the /usr/local/bin/backup command but only on the machine cq-pan. The user jo can execute the adduser command on all machines.  The sudoers man page has a more detail example and explanation.

By allowing you to specify the names of machines you can use the same sudoers file on all machines. This makes it easier to manage a number of machines.  All you do is copy the same file to all your machines (there is a utility called rdist which can make this quite simple).

sudo advantages

sudo offers the following advantages

§         accountability because all commands executed using sudo are logged,
Logging on a UNIX computer, as you'll be shown in a later chapter, is done via the syslog system.  What this means is that on a RedHat 5.0 machine the information from sudo is logged in the file /var/log/messages.

§         menial tasks can be allocated to junior staff without providing root access,

§         using sudo is faster than using su,

§         a list of users with root access is maintained,

§         privileges can be revoked without changing the root password.

Some sites that use sudo keep the root password in an envelope in someone's draw. The root account is never used unless in emergencies where it is required.

Exercises

Every user on a UNIX machine must have an account. Components of a user account can include

§         login names (also called a username),

§         passwords,

§         the numeric user identifier or UID,

§         the numeric group identifier or GID,

§         a home directory,

§         a login shell,

§         mail aliases,

§         a mail file, and

§         startup files.

Configuration files related to user accounts include

§         /etc/passwd,

§         /etc/shadow,

§         /etc/group, and

§         to a certain extent /etc/aliases

Creating a user account is a mechanical task that can and often is automated. Creating an account also requires root privilege. Being the root user implies no restrictions and enables anything to be done. It is generally not a good idea to allocate this task to a junior member of staff. However, there are a number of tools which allow this and other tasks to be delegated.

9.1

For each of the following files/directories

§         describe the purpose they fulfill

§         describe the format of the file

The files are /etc/passwd /etc/group /etc/skel

9.2

Your company is about to fire an employee. What steps would you perform to remove the employee's account?

9.3

Set up sudo so that a user with the account secretary can run the Linux user management commands which were introduced in this chapter.