Objectives| Introduction| A UNIX Account| Special Accounts| Account Configuration Files| Creating a New Account| Deleting an Account| Automating the Procedure| Allocating Super User Privilage| Conclusion| Review Question

Section 6

USERS AND ACCOUNTS

Objectives

• be aware of the processes involved in creating and removing user accounts from a UNIX system,
• have learnt about the various files that hold information about the users of a UNIX system, and
• be familiar with how the processes of adding and deleting a user account can be automated.

Introduction

Users present two major problem areas to Systems Administrators the technical, and

• Modifying configuration files, changing permissions and setting up the system so that the users can actually log onto the machine. the non-technical.
• Responding to pleas for help, criticism and demands, and informing users of changes in the system.

A UNIX Account

• login names (also called a username),
• passwords,
• a user identifier number (referred to as a UID),
• a group identifier number (referred to as a GID),
• home directories,
• mail aliases,
• a mail file, and
• a variety of startup files.

Login names

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 higher number of users it is likely that you may get a number of jonesds.

Some guidelines for the creation of usernames include

• login names should be unique,
  This includes 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.
• they should be no more than eight characters long,
  UNIX ignores or disallows login names that are longer.
• login names are usually all lower case letters,
  Numbers and upper case letters can be used. Login names that are all upper case should be avoided as 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.
• login names should be 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?"
• do not use pseudonyms or nicknames, and
  One of the purposes of login names is to enable other users to identify who is on the system. Users may not know about nicknames.
• they should follow a fixed system 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

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. (Section 14 on security discusses passwords and breaking them in more detail).

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 who 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 (see Section 14).
• do not use combinations of just words and numbers,
  Passwords like hello1 are just as easy to crack.
• 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. a.big1p
• change passwords regularly, and
  Not too often that you forget which password is currently set.
• never reuse passwords.

• asks for the old password,
  To make sure you are the user who owns the account.
• asks for the new password, and
• asks for the new password again.
  Just to check that you didn't make a typing mistake.

The User Id Number (UID)

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 usually reserved by some systems for use by system accounts. Different systems will have different possible maximum values for UID numbers.
• 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 it is owned by the user with a particular UID. The new user will now own those files even though the username has changed.

The Mail File

The mail files for all the users on a machine are kept in the same directory. The location of this directory can change depending on the operating system being used. Common locations are /usr/spool/mail /var/spool/mail /usr/mail /var/mail.

Aliases

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

	postmaster:   root

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 sent to 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.

Home Directories

For example:
A user jonesd might have a 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.

The Startup Files

All these files work by modifying the execution of specific commands. Many of them .cshrc, .profile and /etc/profile (for example) work by modifying the behaviour of the login shell. These shell startup files are responsible for

• setting up command aliases,
  Some shells allow the specification of aliases for various commands. A common command alias is dir, usually set to mean the same as ls -l.
• setting terminal types, and
• search paths.

Filename	Command		Explanation

$HOME/.cshrc	/bin/csh	Executed first when logging in for C shell.
				 Executed every time C shell started.  Used
				 to set things needed for each C shell
$HOME/.login	/bin/csh	Executed after .cshrc when logging in
				 for C shell.
/etc/profile	/bin/sh		Global startup file for Bourne shell. 
				 Used to set machine standard settings
$HOME/.profile	/bin/sh		Located in users home directory. 
				 Contains user specific settings.
$HOME/.logout	/bin/csh	executed just prior to the system logging
				 the user out
$HOME/.forward	mail		Used to forward mail to another address that
				 is contained in the file
$HOME/.exrc	vi		used to set options for vi
$HOME/.mailrc	mail		used to set mail options, aliases etc.

	$HOME is a shell variable that indicates a users home or login directory.
		Table 6.1. Sample Startup Files.

Exercise 6-2. Create a .logout and a .login or .profile that maintains a file account.usage in your home directory. The contents of the file account.usage should look something like this

	Logged in Thu May 26 11:53:37 EST 1994
	Logged out Thu May 26 11:58:37 EST 1994
	Logged in Fri May 27 11:00:35 EST 1994

Special Accounts

Username	UID	Purpose

root		0	The super user account used by the Systems Administrator.
			 Can do anything they want, has no restrictions.
daemon		1	The owner of many of the system daemons.
bin		2	The owner of many of the standard executable programs.

	Table 6.2.	Special User Accounts.

Account Configuration Files

Table 6.3. lists the configuration files examined and their purpose. Not all systems will have the /etc/shadow file. In some cases the shadow file will exist but its filename will be different.

	File		Purpose

	/etc/passwd	password file, contains a list of users and
			 most of their information
	/etc/shadow	shadow password file, contains encrypted password
			 for users on more secure/modern systems
	/etc/group	group file, contains a list of the systems groups
			 and their members

		Table 6.3. Account Configuration Files.

The /etc/passwd File

Table 6.4. summarises each of the fields in the /etc/passwd file.

Field Name		Purpose

login name		user's login name
* encrypted password	encrypted version of the user's password
UID number		the unique User Identification number used
			 by UNIX to identify the user
default GID number	the Group Identifier number used to group users
comment field		no strict purpose, usually contains full name
			 and phone number of user
home directory		the directory into which the user is placed on login
login shell/program	the program that is run for the user as they login
			 (usually a shell)

	* on systems with the /etc/shadow file there will be no encrypted password
		Table 6.4. Fields of the /etc/passwd file.

The /etc/shadow File

The problem with everyone being able to read the /etc/passwd file is that everyone can also read the encrypted passwords contained there. The method used to encrypt the passwords is supposedly a one way encryption algorithm. This means that people trying to break into a system cannot break into the system by running a program that decrypts the passwords.

However what they can do is obtain an on-line dictionary of words and encrypt the whole dictionary. This provides them with a list of encrypted words that can be compared with the encrypted passwords from the /etc/passwd file. If an account has a simple word as the password then the encrypted password will match one of the encrypted words from the dictionary. With a carefully chosen dictionary between 10-20% of passwords can be broken on any machine (discussed in Section 14).

To get around this problem recent versions of the UNIX operating system will not store the encrypted password in the /etc/passwd file. It has been moved to the /etc/shadow file. The shadow file can only be read by the super user.

The shadow file can also go under a number of different names depending on the version of UNIX being used.

The shadow file is a recent addition to UNIX systems and provides a more secure method for storing the user's encrypted password. Typically the shadow file consists of one line per user containing the encrypted password and some additional information. Figure 6.1 lists some of the fields encountered in a typical shadow file.

• username
• encrypted password
• 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
• an undefined flag

  Figure 6.1. Example Fields of an /etc/shadow file.

• a minimum time period before a password can be changed,
  This prevents users from changing passwords every day.
• a maximum number of days a password can be used, and
  Forces users to change passwords after a set time period. Prevents them from using the same password forever.
• a number of days before the account will automatically expire.

	ba012:FjmJeOIdfeKcE:8903:0:99999:7:0:0:0
	ba015:OsR54f8BVxRTI:8905:0:99999:7:0:0:0
	ba014:NPd32s/JvzCRg:8905:0:99999:7:0:0:0

Hint: try looking in the /etc directory, try the man pages for passwd.

Exercise 6-4. Does your system support some form of password aging?

The /etc/group File

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 angels. Any program that provides Internet access has as the group owner the group angels and is owned by the root user. Only the group owner and the owner may execute these files.

The /etc/group file maintains a list of the current groups for the system and the users that belong to each group. /etc/group is like /etc/passwd in that it is colon delimited text file. Figure 6.2 summarises the fields of/etc/group.

• group name
  A unique name for the group.
• encrypted password (this is never used)
• group identifying number (GID)
  GID is similar to the UID only it is used for groups.
• list of user login names who belong to the group, the list is separated by commas.

  Figure 6.2. Fields of the /etc/group file.

	friend::101:davido,david
	staff::102:carterb

Creating a New Account

• modifying the /etc/passwd file,
• set an initial password,
• modify the /etc/group file,
• create the home directory,
• create the new user's mail file,
• create any startup files required for the user, and
• test that the addition has worked.

Prerequisite Information

	Information				My Site

	username format
	user's personal information
	user's group
	location of user's home directory
	location of mail boxes
	user's startup shell
	location of skeleton startup files

		Table 6.5. Requisite Knowledge for Adding a User.

Modify the /etc/passwd file

• appending information to the /etc/passwd file,
  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 that invokes an editor so the Sys Admin can edit the passwd file safely. The command performs some additional steps that ensures the editing is performed consistently.
• a dedicated adduser program.
  Many systems provide a program (the name will change from system to system) that accepts a number of command-line parameters that specify the values for each of the fields of the passwd file.

Set an initial password

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 change immediately any password set by the Systems Administrator.

Modify the /etc/group file

Make the home directory

For example:

	mkdir home_directory
	chown login_name home_directory
	chgrp group_name home_directory

• user owner should be the owner of the account,
• group owner should be the primary group the account belongs to (the one listed in /etc/passwd),
• at the very least the owner of the directory should have rwx, and
• the group and other permissions should be set as restrictive as possible (possibly to none at all).

Creating the Mail File.

The permissions of a mail file should allow

• the user needs to be able to read and write the file so the mail can be read and deleted (the user should own the mail file),
• the group owner should be group mail and it should be able to read and write the file
  The programs that deliver mail to the file are owned by the group mail. It needs to be able to write to the file to deliver the mail.
• no-one else should have any access to the file
  No-one wants anyone else peeking at their private mail.

Creating a mail file for the user david
touch /usr/spool/mail/david
chown david /usr/spool/mail/david
chgrp mail /usr/spool/mail/david
chmod 660 /usr/spool/mail/david

Copy any startup files

Verify the addition

The super user does not need the user's password to login as that user, they can use the su command.

For example:

su - david Simulates a full login as the user david. This actually forces all the startup files to be executed. If this command is executed as the root user no password will be prompted for.

Inform the user

Deleting an Account

Change the password field

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

Back up the user's home directory and contents

Remove the user's files

Depending on the system it may be a good idea to take a backup copy of the user's files before removing them.

Mail for Old Users

However what happens if the user has moved onto a new machine and would like their mail forwarded? One solution is to create a mail alias for the user that points to their new address.

Automating the Procedure

#!/bin/bash
# FILE:         /usr/local/adm/bin/makeeuser
# FORMAT:       makeeuser [username]
#                         [username "comment"]
#                         [username "comment" home_dir]
#               username is the new username 
#               "comment" is the GCOS information for the account
#               home_dir is the home directory of the account
# AUTHOR:       David Jones (based on a script by Chris Parry)
# PURPOSE:      Creates a new user account. 
#		  The script does very little checking as it relies
#		  on the supplied useradd command to do much of it for us.
# HISTORY:      makesuser Created 27/03/94
#		makeeuser started 2/6/94

home_dir='/home/os'
email=/tmp/asemail$$
init_group='os'
login_shell='/bin/bash'  
admin_address='david@bertha'		# addres to send notification
welcome_mail='/usr/local/extern/welcome'

trap "" 1 2 3 15

if [ `whoami` != "root" ]; then
  echo "Only root may add users to the system."; exit 1
fi

# Get the login name of the user.
if [ "$#" -lt 1 ]; then
    echo -n 'Enter login name: '
    read username junk
else
  username="$1"
fi
# Convert extern name to lower case.
username=`echo $username | tr "[A-Z]" "[a-z]"`

# Get the account description field.
if [ "$#" -le 1 ]; then  
  echo -n 'Please input the Users full name==> '
  read comment
  echo -n 'Please enter the Users student number==> '
  read student_num
else
  comment="$2"
fi

# Get the location of the home directory of the account.
home_dir=$home_dir/$username

# Create the new extern user account.
# Add a new extern account and the first extern administration account.
/usr/sbin/useradd -c"$comment" -d$home_dir -m -k/etc/skel -g$init_group -s$login_shell $username

# Make sure the home directory of the account exists.
if [ -d "$home_dir" ]; then
  # Create a mail file for the account.
  touch /usr/spool/mail/$username
  chmod 660 /usr/spool/mail/$username
  chown $username /usr/spool/mail/$username
  chgrp mail /usr/spool/mail/$username
  # Set the password life of the account.
  passwd -x 365 -n 0 $username
  # Record the account creation details into a temporary account to be
  # mailed to administration when completed processing.
 
fi

if [ $# -eq 0 ]
then
  passwd $username
fi

Allocating Super User Privilege

• how do you set a password without having to type it in yourself, and
  If you are creating 300 new user accounts you don't want to have to think of new passwords for each user and then enter them yourself. The best solution would be to have a program generate and set them for you. The problem here is that the passwd command requires input from the user and redirecting input from another program won't work. This means you can't automate on the passwd command so you can't do it easily from a shell script.
• how do you let an offsider handle the menial task of adding a user without giving them root access?
  Creating new accounts is a fairly mundane job especially when it is automated. A Systems Administrator is typically better occupied doing something more complex. It would be nice to be able to let someone with less responsibility do this task. But how do you let them do this without giving them the root password?

Program Name	Purpose	Location

sudo		Allocate specific root		ftp.connect.com.au
		 on a user by user basis	 /pub/security/sudo.v1.2.tar.Z
expect		provide the ability to use	ftp.connect.com.au
		 interactive commands from	 /pub/misc/expect.tar.Z
		 a shell script without
		 user intervention

		Table 6.6. Sudo and expect.

Using existing software instead of writing your own is a good example of another Systems Administration maxim, "Never reinvent the wheel". If someone else has already solved a problem it is stupid for you to waste your time trying to solve it again.

Exercise 6-6. Write a shell function get_uid that returns the next free UID number. (Some systems by default have a user with a very high UID. This means you can't just sort the passwd file on UID and get the last entry.)

Exercise 6-7. Write a shell function make_username that accepts a user's firstname and lastname as parameters and then sets a variable username. username is to contain a username for this user using the format, first seven letters of the surname followed by the first initial. For example: David Jones turns into jonesd Georgina Pickering turns into pickerig

Conclusion

Review Question