Practical Linux System Administration

Chapter 4. Managing Users

As a system administrator, you’ll spend a significant portion of your time managing users. You’ll also spend time troubleshooting user problems that aren’t account- or permissions-related, such as connectivity problems, broken applications, data corruption, training issues, security issues, and user-created problems.

Managing users covers the following tasks:

• Creating user accounts

• Modifying user accounts

• Removing user accounts

• Granting access to files and directories

• Restricting access to files and directories

• Enforcing security policies

• Setting permissions on files and directories

Some user management tasks can be learned from this book, while others are purely experiential and on-the-job training for you. No two user environments are exactly alike, and no two user experiences are exactly alike. In this chapter, you learn some preemptive user management methods, but problems still occur. The techniques you learn in this chapter will get you started on being able to handle an array of user-related problems.

User and Group ID Numbering Conventions

There are some guidelines associated with creating and maintaining user accounts on Linux systems, as shown in Table 4-1. These aren’t hard and fast rules, but they’re generally followed on most corporate systems.

Table 4-1. Numbering conventions for user and group accounts

UID	GID	Description
0	0	Root
1–999	1–999	System/service accounts
1000+	1000+	User accounts

User account UID and GID numbers typically begin at 1000 and increment by one for each new account. The UID and GID for the root user are always 0; no other user on the system has these user and group IDs.

System and service accounts aren’t human user accounts and typically don’t have an interactive shell associated with them. These accounts are given UIDs and GIDs ranging from 1–999. These separations make system housekeeping much easier than randomly assigning UIDs and GIDs to user accounts.

Creating User Accounts

Like most tasks in Linux, there’s more than one way to create user accounts. For this book, I stick with the two mainstream methods of creating accounts: useradd and adduser.

Adding Users with useradd

The useradd command is the standard command-line Linux method of adding new users to a system. The useradd command is simple; all you really need to supply is a username as an argument:

# useradd jsmith

This creates the home directory, /home/jsmith, fills it with the default complement of hidden environment files, and places an entry into /etc/passwd. When I create a user account with useradd, I supply a single argument and bit of information (the user’s full name) that otherwise requires me to edit the /etc/passwd file:

# useradd -c "Jane Smith" jsmith

The -c option writes the information you supply to it to the fifth field of the /etc/passwd file. If you wish to supply more information, such as phone number, email address, or whatever you wish to include, use commas (,) to separate the information:

# useradd -c "Jane Smith,Room 26,212-555-1000,[e-mail]" jsmith

The new user’s /etc/passwd entry:

jsmith:x:1007:1007:Jane Smith,Room 26,212-555-1000,[e-mail]:/home/
jsmith:/bin/bash

The individual fields in a user’s /etc/passwd entry are as follows (from left to right):

• Username

• /etc/shadow password field

• User ID

• Primary group ID

• The comment field

• Home directory

• Default shell

Passwords are not stored in the /etc/passwd file. The /etc/shadow field refers to the /etc/shadow file that contains each user’s encrypted password and is readable only by the root user. Note the /etc/shadow file’s permissions are 000 on Red Hat Enterprise Linux–based systems. The file permissions vary among distributions but are never readable by regular users:

----------. 1 root root 1547 Jul 17 10:55 /etc/shadow

Although Jane Smith’s user account is created, her home directory exists, and there’s an entry in the /etc/passwd file for the account, Jane can’t log into the system. Do you know why? It’s because the account has no password. As the sysadmin, you have to supply an initial password to Jane so that the user can log in. Since you haven’t supplied a password for the account, the /etc/shadow entry shows that there is no password:

jsmith:!!:18825:0:99999:7:::

Use the passwd command to supply a password to the account:

# passwd jsmith
Changing password for user jsmith.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Now, you have to give the password to Jane before she can successfully log into the system.

Adding Users with adduser

On some Linux distributions, adduser is a symbolic link to useradd:

lrwxrwxrwx. 1 root root 17 Oct 26 2020 /usr/sbin/adduser -> /usr/sbin/useradd

On other distributions, adduser is an interactive Perl script that steps you through adding a new user, and useradd is a separate utility with its standard switches and arguments.

Modifying User Accounts

There’s rarely such a thing as a static user account. Therefore, the usermod command exists to assist you in making those required changes without editing /etc/passwd, a home directory, or configuration files. The usermod command is the catchall for changing all things user account related. The following is an abbreviated list of modifications that you can make with the usermod command:

• Add the user to a supplementary group

• Change the user’s comment field in /etc/passwd

• Change the user’s home directory

• Set an account expiry date

• Remove an expiry date

• Change a user’s login name (username)

• Lock/unlock a user’s account

• Move the contents of a user’s home directory

• Change a user’s login shell

• Change a user’s ID

Some of these options are more frequently used than others. For example, it’s completely reasonable to change a user’s login shell, lock and unlock an account, set or remove an expiry date, or add a user to a supplementary group. Changing a user’s ID once it’s set during account creation is rare, as is relocating a user’s home directory.

In the following sections, I give examples of the most commonly requested user account changes. Check the man page for details if you need to alter other aspects of a user’s account.

Adding a Supplementary Group

When you create a new user account, the system assigns the user a user ID (UID) and a primary group ID (GID). (They can be the same sequential number, but that isn’t always the case.) For example, for the account created earlier for Jane Smith, the UID is 1007, and the GID is 1007:

jsmith:x:1007:1007:

Jane’s primary GID is 1007, but she might also work in an area of the company, such as IT, engineering, or application development, that requires her to have access to a group-owned directory. For this exercise, Jane works in the engineering department as an associate engineer. The engineering department’s shared directory GID is 8020. Using usermod, here’s how to grant Jane access to that group’s shared directory:

# usermod -a -G 8020 jsmith

This adds Jane’s user account to the engineering group in the /etc/group file:

engineering:x:8020:bjones,kdoe,vkundra,adundee,jsmith

Now Jane can access the engineering group’s shared directory. To correctly add Jane’s account to a new group, use the -a (append) and the -G (supplementary group) together. For example, if you want Jane to access the finance department’s shared directory, you must append her to that group. When adding a user, you can use the GID number or the group’s name:

# usermod -a -G finance jsmith

Warning

You must use the -a (append) and the -G (supplementary group) together. If you don’t use the -a option, your user will be removed from all other supplementary groups and added only to the one you specify.

A user can be a member of several other groups. For example, a user might be in the finance department (GID 8342) but also require access to human resources (GID 8901) information. You can also add a user to more than one group at once:

# usermod -a -G 8342,8901 jsmith

This command adds Jane Smith to the finance and the human resources group with a single command.

Changing the User Comments Field

Changing the user comments (GECOS) field is a common task. You can edit the /etc/passwd file directly, although it comes with significant risk. The rule of thumb is that if there’s a tool to perform some action or task, you should use it rather than directly editing configuration files. You can easily change the GECOS field using the usermod command and the -c option. 

Let’s say the company has recently hired a second person named Jane Smith, so you need to distinguish between them by adding a middle initial to the first Jane Smith’s GECOS field:

# usermod -c "Jane R Smith" jsmith

This command replaces Jane Smith with Jane R Smith.

The -c option tells the usermod command that you’re editing the “comments” field. You can also change this information using the chfn command:

# chfn -f "Janie Smith" jsmith

The chfn command changes your finger information. Finger is an old daemon that ran on early Unix systems and some Linux systems and supplied information about users. Almost no one uses it these days because of security issues, but the information is still referred to as finger information. The -f option changes the user’s full name field for the specified account. There are other options for office (-o), office phone (-p), and home phone (-h). Generally, only the user’s full name or the service’s name and purpose are used for the GECOS field.

Setting an Expiration (Expiry) Date on an Account

If a user gives notice at a company, moves to a different business unit, or goes on parental leave, sysadmins might decide to disable that user’s account for security reasons until the person returns or before removing the account from a system:

# usermod -e 2021-07-23 rsmith

Rob Smith’s account will be disabled (expired) on the specified date in the format YYYY-MM-DD. The -e option sets the account for expiration.

Changing a User’s Login Shell

The default Linux shell is bash, but some users prefer to use a different shell, so they request that their default shell be changed to one of the many other available shell options. There are three methods of changing a user’s default shell: usermod, chsh, and directly editing /etc/passwd. Direct editing of the /etc/passwd file is not recommended.

The usermod command method uses the -s option, the new shell, and the username to make the change:

# usermod -s /bin/sh jsmith

The updated /etc/passwd file is shown here:

jsmith:x:1007:1007:Janie Smith:/home/jsmith:/bin/sh

Only a user with root privileges may edit the /etc/passwd file or use the usermod command. However, any user may change their shell with the chsh command:

$ chsh -s /bin/zsh
Changing shell for jsmith.
Password:
Shell changed.

The resulting /etc/passwd entry is as follows:

jsmith:x:1007:1007:Janie Smith:/home/jsmith:/bin/zsh

For other changes, consult the man page for usermod.

Note

At the end of any man page, you’ll find a list of related alternative commands, links to external documentation, and configuration files referenced in the “See Also” section. These are handy to explore and might prove more efficient for making changes. The following is the “See Also” section excerpted from the usermod man page:

See Also

chfn(1), chsh(1), passwd(1), crypt(3), gpasswd(8), groupadd(8), groupdel(8), groupmod(8), login.defs(5), useradd(8), userdel(8).

Now that you’ve learned to create and modify user accounts, let’s discuss how to remove user accounts.

Removing User Accounts

Fortunately, system administrators and developers who give names to commands do so in a way that makes them easy to remember. Command names often describe their functions. The useradd command is one such example. To remove a user account from a system, you use the userdel command, which is just as easy to use as useradd is.

To remove a user account from your system, issue the userdel command and supply the username for the account:

# userdel jsmith

This command removes the user’s entry from /etc/passwd and from /etc/shadow but leaves the user’s home directory (/home/jsmith) intact. Why do you think that’s a good option? Sysadmins often leave a user’s home directory intact after a user has separated from a company or has changed jobs within the company but no longer requires access to a system. Retaining the user’s home directory ensures that only the root user can access any documents left by the user that might be important to the company.

If you make nightly backups of users’ home directories, you don’t necessarily need to retain the user’s home directory. The following userdel command removes the user’s home directory and all files inside it:

# userdel -r jsmith

Warning

Destructive Linux commands, such as userdel and rm, are irreversible and can’t be undone once executed. Always be sure that you have the correct user account before pressing the Enter key—and have good backups.

When it’s time to change passwords, you need to know how to force users to do it. Our next section shows you how.

Forcing Password Changes

It’s a matter of trust that the user will change their password when you provide them with an initial password. Sysadmins who regularly audit their users’ passwords realize that this “honor system” level of trust doesn’t work 100% of the time. You can easily audit a user’s account settings using the chage command. The -l option lists the current settings for the specified user account:

# chage -l rsmith
Last password change                    : Jul 17, 2021
Password expires                        : never
Password inactive                        : never
Account expires                        : never
Minimum number of days between password change    : 0
Maximum number of days between password change    : 99999
Number of days of warning before password expires    : 7

As you can see, this account’s password never expires, which is a security violation that needs to be fixed. In addition to a regular forced change, you should also set a minimum change period. For example, as shown in the following code listing, I set the rsmith account to force a password change every 90 days (-M 90) with a minimum number of days between password changes to 1 (-m 1). Setting a minimum number of days ensures that users don’t change their passwords 10 times (or whatever the number of the system’s remembered passwords is set to) to reset it to their original password, which amounts to no net password change.

# chage -m 1 -M 90 rsmith

# chage -l rsmith
Last password change                    : Jul 17, 2021
Password expires                        : Oct 15, 2021
Password inactive                        : never
Account expires                        : never
Minimum number of days between password change    : 1
Maximum number of days between password change    : 90
Number of days of warning before password expires    : 7

The expiration date set by the system is 90 days after the last password change. If the last password change is in the past, the user must change their password on the next login.

Note

From the chage man page: “The chage command changes the number of days between password changes and the last password change date. The system uses this information to determine when users must change their passwords.”

Passwords are a weak form of authentication because they can be guessed, cracked, or read in plain text if users write them down. Thus, you must ensure that passwords are changed often and not reused.

Handling Service Accounts

Nothing stirs controversy among sysadmins and security administrators like the mere mention of service accounts. I’m not sure what all the controversy is about because every Linux system has more than 30 service accounts.

An example of a service account is the nobody account, which is the Kernel Overflow User account:

nobody:x:65534:65534:Kernel Overflow User:/:/sbin/nologin

Generally, you can spot a service account because in the /etc/passwd file, you see that the user account has no assigned shell. Service accounts have /sbin/nologin, where the user’s shell should be. This means that the service accounts have no interactive shell or passwords. That doesn’t mean their passwords are blank or null, they simply don’t exist. In other words, if a user account has /sbin/nologin as their shell, they can’t log into the system with any password. And no user, not even the root user, can su or sudo to those accounts:

# su - nobody
This account is currently not available.

Because service accounts have no interactive shell and no method of switching to one via su or sudo, there’s no security violation associated with having service accounts on a system. The controversy comes from the fact that some system administrators don’t know that service accounts don’t usually have interactive shells or passwords. Services may require an interactive shell account for their service to function. For those services, extreme scrutiny and other security measures should be in place to thwart potential clandestine logins on those accounts.

Managing Groups Rather Than Users

When managing permissions for a set of users, it’s more convenient to define and manage a group than to manage each user separately. Group management allows you to do the following:

• Manage permissions on assets such as folders and files

• Manage permissions according to job function

• Change permissions for a large number of users rather than for each user individually

• Easily add users to and remove users from a group’s shared folders and files

• Restrict permissions to sensitive folders and files

It’s very difficult to manage permissions for individual users because if those permissions need to change, you have to trace permissions for that user on every system on which they have an account. Managing permissions for groups allows sysadmins to manage fine-grained user access on a more global level.

For example, if you have a user who works in the human resources (HR) department and then moves to the finance department, it’s easy to remove that user from the HR group and add them to the finance group. The user immediately has access to all shared files and folders that other finance group members do. And the user no longer has access to HR files and folders.

You learned earlier in this chapter how to add users to supplementary groups. You should practice adding directories to the system, adding a group account, setting that particular group ownership to the directory, and then adding users to the group. You can then su - username, becoming that user to test your permissions settings.

The following is one possible scenario for you to work through to learn group management. This example assumes you already have a finance group and users assigned to it. Notice that during this example, the root user exits and returns to a regular account that is part of the finance group. And users can change group ownership and permissions of files they own:

$ su - root
Password:

# mkdir /opt/finance

# chgrp finance /opt/finance

# ls -la /opt
total 0
drwxr-xr-x.  3 root root     21 Aug 11 21:56 .
dr-xr-xr-x. 18 root root    239 Aug 11 21:08 ..
drwxr-xr-x.  2 root finance   6 Aug 11 21:56 finance

# chmod 770 /opt/finance

# ls -la /opt
total 0
drwxr-xr-x.  3 root root     21 Aug 11 21:56 .
dr-xr-xr-x. 18 root root    239 Aug 11 21:08 ..
drwxrwx---.  2 root finance   6 Aug 11 21:56 finance

# exit
logout

$ cd /opt/finance

$ touch budget.txt

$ ls -la
total 0
drwxrwx---. 2 root  finance 24 Aug 11 21:58 .
drwxr-xr-x. 3 root  root    21 Aug 11 21:56 ..
-rw-rw-r--. 1 khess khess    0 Aug 11 21:58 budget.txt

$ chgrp finance budget.txt

$ ls -la
total 0
drwxrwx---. 2 root  finance 24 Aug 11 21:58 .
drwxr-xr-x. 3 root  root    21 Aug 11 21:56 ..
-rw-rw-r--. 1 khess finance  0 Aug 11 21:58 budget.txt

$ chmod 660 budget.txt

$ ls -la
total 0
drwxrwx---. 2 root  finance 24 Aug 11 21:58 .
drwxr-xr-x. 3 root  root    21 Aug 11 21:56 ..
-rw-rw----. 1 khess finance  0 Aug 11 21:58 budget.txt

If you understand everything that’s going on in this example, then you’re ready to move on to the next chapter. If you haven’t yet mastered these concepts, work through the chapter examples again and return to this exercise. Remember that creating users, groups, and directories and changing permissions are daily tasks for sysadmins, and practicing these skills is the only way to acquire them and become comfortable using them.

Summary

This chapter taught you how to create, remove, and change user accounts. You also learned how to set up service accounts and had a brief overview of managing groups. In the next chapter, you will learn about Linux networking, from the basics of why networks are important to more-complex concepts such as network troubleshooting.