Managing Users Objectives Contents Practicals Summary to be able to add, modify and remove Unix user accounts Contents requirements for a user account configuration files (passwd, shadow) adding users modifying user details passwords deleting users working with groups Practicals to add several user accounts Summary This chapter looks at the management of users, user accounts and groups. What to do when adding new users or removing old users.

New User Requirements An entry in /etc/passwd, which will define the user login name user id default group descriptive name login program (shell) An entry in /etc/shadow, which will control account access initial password password aging information An entry in /etc/group, for the default group assignment one of the existing groups in this file will become user's primary group user access to other than primary group can be allowed in this file And somewhere to store files a home directory an initial .bash_profile and application startup files A new user requires an account and working environment within the Unix system. The system administrator must set this up before the user can log on. Most of the items on the slide are compulsory, others, like the profile and application files are optional. A good administrator will provide a default profile for all new users and an initial welcome message telling the user who to contact for help or further information. The steps and utilities used in setting up a user are straightforward and easy to use. The most significant aspect when adding a user is planning how that user is going to fit in the system. Which group will he belong to, what id number, indeed what user name. First names are often used for login names, creating potential problems if you later have another user with the same name. Motto of the story: plan ahead, then actual setup will be easy and correct!

Preparing Groups (/etc/group) Use groups for working on projects and in departments groups provide a second level of access control groups will allow users to share files Setup groups before adding new users One line per group in /etc/group name::gid:user1,user2 Entry for a new group added with groupadd utility To change or remove group use groupmod and groupdel group name list of users allowed 'secondary' access to this group numeric id The main function of the /etc/group file is to define valid system groups and provide a cross-reference between user-friendly group names and computer-friendly numbers. Each line in the group file corresponds to a group. These usually reflect the structure of your company or department. Groups should relate to the type of work that will be performed by the users belonging to each group, as it will control how the files can be shared between them. Only the groups setup in this file can be used when assigning the primary group to the user (we will do it in a moment). It is therefore important that you setup this file with a lot of thought, before you start adding users. The groups can have passwords supplied in the second field, but very few sites utilise this feature. Password protected groups can be set by any user knowing the password (use the newgrp command). Normally, group passwords are disabled (with the asterisk) and the list of permitted users within the group is given in the last field. # groupadd -g 151 swamp # groupadd -g 152 barracks

name::UID:GID:comment:home directory:shell The /etc/passwd file Each valid user must have an entry in this file One line per user of the form name::UID:GID:comment:home directory:shell name must be unique, up to 8 alphanumeric characters, usually lower case UID user id, a numeric value within the range of 0 to 65535 GID user primary group, a numeric value within the range of 0 to 65535 comment this field is free format text, usually fuller description of the user home directory this is the account location, usually under /home shell startup program, it is optional (but last colon isn't) if no value given, it defaults to /usr/bin/sh recommended shell is /usr/bin/ksh the shell can be any executable program The layout of the password file entries is shown on this slide. Every user of the system must have an entry in this file before they will be able to log into the system. Each entry defines a login name and equivalent user id number. Additional fields encode the password, home directory, login program and full user name. The login name must be unique. The password is usually held in the shadow file rather than here, as every user needs access to this file. The user id is usually unique, but need not be. It may be required to have two logins with the same id, and two different login programs. Beware of duplicated user ids of 0. This may mean that you have more that one superuser on your system (this issue will be discussed again later). Systems with administration utilities allocate user ids automatically. Most people simply use the value suggested and rarely run into problems. In a networked environment, it is advisable to synchronise user ids across all machines. Otherwise, user 103 on one machine may be allowed to read another user's data if the other user has id 103 on a different machine. Basing user ids on personnel numbers (guaranteed to be unique) can be useful, as the user's login name can be related back to a personnel number. Obvious uses are for semi-automated time sheets, departmental accounting or simply integration of site-wide information. The login program need not be a ‘shell’, any program can be used, such as a database application. $ grep root /etc/passwd root:x:0:0:root:/root:/bin/bash operator:x:11:0:operator:/root:/sbin/nologin

Allocating User IDs (UIDs) Zero always used by root Entries less than 100 refer to special system accounts root superuser - unrestricted access to entire system daemon looks after background processes bin owns most system commands sys owns most system files adm owns some administration files uucp owns uucp files and processes nuucp login used by uucp lp line printing subsystem User accounts normally start at 100 or higher each user should have a unique user id networked systems should use consistent user UIDs All unix systems come with several administrative users pre-setup. Some of them are intended for login while performing certain admin work, such as user lp. Other system users are not for login purposes and will be used internally by the system only. The administrative system users are typically assigned UID less than 100. Never modify any admin, system generated, user details (except for the password, perhaps). The user with the UID=0 is the superuser. There is nothing special about the user name root. It is not this name that gives root privileges. It is the fact that UID is 0. Consequently, if you add a new user with UID of 0, and give him shell as the strartup program, you have created another superuser. One technique in choosing numeric id for users is to use the group they will belong to as a base for ids. For example, if you created two groups: purchase::500 sales::800, give all users belonging to purchasing department ids in the 500-599 range and all users in sales in the 800-899 range.

Adding Users Don't edit the control files manually Use utilities such as useradd (SVR4), mkuser (AIX) useradd creates required record in /etc/passwd and /etc/shadow files allows to create directory structure for the new user Useful options to useradd to override defaults -u uid specify new user id (default: next available number) -g group specify default group (default other, GID=1) -c comment description of user (default blank) -d dir home directory -m make home directory (recommended, default /home/username ) -k skel_dir skeleton home directory (default /etc/skel) -s shell specify login program (default /bin/bash) Don't forget to give the user an initial password The useradd utility is available on most SVR4 implementations and is recommended for administering users. It allows you to modify configuration files without having to edit them directly. Sorry to deprive you of using your most favourite, vi, editor, but well-being of the system config files takes higher priority. The options used with the useradd command are shown above. Use useradd -D to see the default values for adding a new user account. These defaults will be used if you don't provide account details yourself. It is strongly recommended that you ask useradd to create the home directory for the new user. Bear in mind, that usermod will ensure that the home directory has all the permissions set properly, in other words it will run for you the chown and chgrp commands. If you forget this, you will have to do it all manually. The skeleton directory allows you to configure a kind of template directory structure you intend to provide to new users. When requested with the -k option, useradd will recreate this skeleton directory within the home directory of the new user, again, making sure that the assess permissions are set accordingly. # useradd -m henry # useradd -u 321 -g 200 -m -s /bin/bash hotlips

Changing User Attributes Don't edit the control files manually Use supplied utilities such as usermod (SVR4), chuser (AIX) usermod uses the same basic set of options that are used with useradd if you modify UID then use -U option as well, to change the UID of files belonging to the user, but... ...only files in user's home directory, mail file and cron file will be affected, other files must be located and ownership modified manually Account inactivity and expiry date can also be set by usermod # usermod -g users -c "Henry Blake" henry # usermod -U -u 321 -s /bin/bash hotlips Same warning as before applies: if you edit files manually, you are risking file corruption resulting with users not being able to log in at all! There is a good degree of compatibility between options used here and those used by the sister program, useradd. Notice the -U option. Very useful if you are modifying user's numeric id. If you don't use this option, the files currently owned by the user will still belong to the original UID, even though the new value will be recorded in the /etc/passwd file. Only files created after UID was modified will have the new value kept in the inode table. It may be that this is what you want, just beware of the issue. usermod can also be used to set a couple of attributes associated with the password control, namely to set the inactivity counter and the absolute date beyond which the account will be locked. More about password control later... # usermod -f 10 henry # usermod -e 01/31/05 hotlips

Changing Group Membership Each user belongs to a group (defined in /etc/passwd) primary membership can be changed with usermod -g User can also be allowed access to other groups secondary membership is controlled by usermod -G the group must already exist # grep trapper /etc/passwd trapper::416:400::/home/trapper:/bin/bash # groupadd -g 600 swamp # usermod -G swamp trapper # grep trapper /etc/group swamp::600:trapper add new group trapper's primary group is 400 add trapper to group 600 (his primary membership unchanged) Users can be assigned to be secondary members of groups other that the one defined in the /etc/passwd file. The last field in the /etc/group file allows you to specify the list of users which will be able to share files with other members of that group. The usermod -G is used for that purpose. Note that there are no spaces between user names and commas in last field and that you do not need an entry in the group file for your default or primary group. Groups tend to be under used in Unix environments. This is unfortunate as intelligent use of groups can simplify working practices and user administration. Encourage your site to make full use of groups. It is better if a team of users working on a project use a group account to store common files rather than allocate files to individual users. When the project is finished, the account can be disabled and all the data archived to recover the file space for a new project. When using group mail, one of the following should happen: The administrator of the group should read the mail, or the mail should be forwarded to the administrator (vacation command). The group should be set up as an alias, so that the mail is sent to all members of the group.

Exercise - Adding and Modifying Users Write down the commands to perform the following: # add a user called frank add a user called radar specifying the Korn shell add a user called klinger using /home2/klinger as the home directory add a user called mulcahy specifying a UID of 400 and a group of staff modify the user frank to use the korn shell modify radar to give him a new UID of 401 The answers to this exercise are provided at the end of this chapter.

Setting Passwords New user accounts have to have an initial password Forgotten passwords have to be reset Verify that the person asking to reset the password is the account owner Use the standard passwd program with a username as root you will not be prompted for an existing password choose a simple password and inform the user verbally Lock the user account # passwd henry new password: retype password: A user account must have a password before it can be used. Users often forget their passwords and ask the system administrator to tell them what their password is. This is not possible under Unix. Instead, the password has to be set to a new value and the user informed of the new password. If password ageing is in force, use the indicated option to expire the password, forcing the user to change the password the next time they log on. Ensure that the person asking for a password to be reset is the account owner. See them in person if possible, and get a signed confirmation from the person concerned. # passwd -l henry

The /etc/shadow file Each valid user must have an entry, of the format: name:password:last change:min:max:warn:inactive:expire:flag name user login name, cross-reference to /etc/passwd file password valid (encrypted) passwords have exactly 13 characters if this field is blank there is no password NP in this field implies no password has been set (login not accessible) LK or * in this field implies the account is never used (locked) last change number of days of last password change since 1/1/70 min minimum number of days between password changes max maximum number of days the password is valid warn number of days before expiry that user will be warned inactive number of inactivity days allowed for this user expire an absolute date, beyond which the account will be disabled The passwords (or rather their encrypted representation) are stored in the /etc/shadow file. The shadow file does not contain uids. The relationship between the password file and the shadow file is by username and position. It is vital that these files are kept in step if hand edited (which we would never do, would we?). $ grep root /etc/shadow root:b93.GT2r.7IZ6:9718:0:60:7:::

Account Security Use preset expiry dates for temporary employees very useful for contract staff Use inactivity counts to lock unused accounts perhaps the user has left the company and no one told you Change passwords known by someone who leaves change ALL passwords if they knew the root password Lock accounts if they are temporarily unused user is on secondment or holiday Use the password ageing mechanism! # usermod -e 12/24/04 hotlips # usermod -f 5 hotlips # passwd -l trapper Users are the biggest security risk for any Unix system. Advising users on sensible passwords can help but there are other actions you can take to improve security. These are explained on the slide. Note that someone with the root password can gain access to the encrypted passwords on the system. If this person then leaves they may take the encrypted password list with them. With the encrypted passwords available it is quite possible for someone to apply standard techniques to guess passwords and thereby break back into your system Many users hate password ageing as it forces them to change their passwords on a regular basis. However companies insist that password ageing is enforced. The password warning time indicates when the user will be asked to change the password before it actually expires. The warning is repeated every day until the user changes the password (or it expires). # passwd -n 27 -x 30 -w 3 radar

Exercise - Account Security Write down the commands to perform the following: # add a password for user frank force frank to change his password at next login enable password ageing for trapper (min 21 max 31 warn 7) set the expiry date for hawkeye to 31 Jan 2005 lock henry's account now unlock henry's account The answers to this exercise are given at the end of this chapter.

Removing User: Preparation When a user leaves there are two main concerns: protect the system from unauthorised access via his/her account protect and manage his/her files and directories left on the system Proposed sequence of steps lock the account password, until you are ready to remove it altogether save all files owned by the user, somewhere outside the home directory change access permission on saved files, allowing access to root only consider cron or at jobs setup by the user set up mail forwarding to send mail to a manager # passwd -l henry # mkdir /hold; chmod 000 /hold # cd / # find . -user henry -print | cpio -ov | compress >/hold/henry # find . -user henry -type f -exec rm -f {} \; # find . -user henry -type d -exec rmdir {} \; # su - henry -c "mail -F bigboss" A user may leave a company or may no longer require use of the system. When this happens, the system administrator must clean up the user's account and mail system. The user's files should be collected together and saved on-line for a short period of time to allow the user's manager to extract any important files. The user's mail should be forwarded to the manager once the mailbox has been emptied. You should also check if the user left behind any cron or at tasks. If you remove user's files with the suggested find command, the files containing the scheduled tasks will go as well. There may be jobs that your system still require and you may need to reassign those to somebody else. Below is the fuller description of the steps suggested in this slide: # passwd -l henry Lock the password # mkdir /hold; chmod 000 /hold Create and protect the directory in which you will store all user's files # cd /; find . -user henry -print | cpio -ov | compress >/hold/henry Create a compressed (cpio format) file of all user's files. Notice that we've changed to root and issued find in current (dot) directory deliberately, to save relative pathnames. This will make sure that when we restore files for inspection, they will not be inserted at different places in the system. # find . -user henry -type f -exec rm -f {} \; # find . -user henry -type d -exec rmdir {} \; Now that we saved the files, we can remove them. Notice, that we have not dealt with any directories that though may have belonged to the user, but contained files owned by others. # su - henry -c "mail -F bigboss" The incoming mail can be redirected to another user. This will work even when we eventually remove the user's account from the system altogether.

Removing User Account Delete user account only when his/her data is safe Use userdel utility (SVR4) or rmuser (AIX) Without any options userdel will leave all files owned by that user untouched and open to misuse. the -r option with userdel will remove user files, but only those in the home directory (including the home directory itself) userdel does not remove mail file more significantly, userdel does not remove user's cron table or stop cron from executing the task scheduled by that user userdel prevents reuse of the UID for a default 30 days UID reuse time (in months) can be specified with -n option # userdel -r henry A user may leave a company or may no longer require use of the system. When this happens, the system administrator must clean up the user's account and mail system. It is best to leave the entry in the log file so that the user id and login name will not be reallocated. The user's files should be collected together and saved on-line for a short period of time to allow the user's manager to extract any important files. The user's mail should be forwarded to the manager once the mailbox has been emptied. Alternatively, the system administrator may wish to use the vacation command to send a message to all users still sending mail to the user. Many systems don't reuse user ids as this can be a source of security problems. New users having access to files owned by the old user but were inadvertently not removed from the system. # userdel -r -n 2 henry

Summary User account information stored in 3 files: /etc/passwd /etc/shadow /etc/group Account information contains: login name password user and group ids full name home directory login shell SVR4 provides utilities for manipulating user details passwd useradd, usermod, userdel groupadd, groupmod, groupdel