Chapter 11
Managing User Accounts
Adding and managing users are common tasks for Linux systems administrators. User accounts keep boundaries between the people who use your systems and between the processes that run on your systems. Groups are a way of assigning rights to your system that can be assigned to multiple users at once.
This section describes not only how to create a new user, but also how to create predefined settings and files to configure the user's environment. Using tools such as the useradd and usermod commands, you can assign settings such as the location of a home directory, a default shell, a default group, and specific user ID and group ID values.
Every person who uses your Linux system should have a separate user account. Having a user account provides each person with an area in which to securely store files, as well as a means of tailoring his or her user interface (GUI, path, environment variables, and so on) to suit the way that he or she uses the computer.
You can add user accounts to most Linux systems in several ways. Fedora and Red Hat Enterprise Linux systems use the User Manager window (system-config-users) utility on the desktop. From Red Hat Enterprise Linux, select System ⇒ Administration ⇒ Users & Groups, and type the root password when prompted. When the window appears, select the Add User button. Figure 11.1 shows an example of the User Manager window and the Add New User pop-up.
You are now ready to begin adding a new user account to your Linux system. Here are the fields you need to fill in:
Select OK to add the user to the system. An entry for the new user account is added to the /etc/passwd file and the new group account to the /etc/group file. I describe those later in this chapter. To modify user information later, or set different information, double-click on the user account you want to change. A User Properties window appears, like the one shown in Figure 11.2.
Most of the information you set before can be changed from the User Data tab. However, select the Account Info if you want the account to expire on a particular date or to lock the password so, temporarily, no one can log in as the user. On the Password Info tab, you can set when a password expires so you can force users to change their passwords after a set length of time. The Groups tab enables you to select check boxes to let a user belong to different groups.
Everything described with the User Manager window can be done from the command line as well. The next part of this chapter describes how to add user accounts from the command line with useradd or change them with the usermod command.
Sometimes a Linux system won't have a desktop available to use the User Manager window. Other times, you might find it more convenient to add a lot of users at once with a shell script. For both cases, commands are available to enable you to add and modify user accounts from the command line.
The most straightforward method for creating a new user from the shell is the useradd command. After opening a Terminal window with root permission, you simply invoke useradd at the command prompt, with details of the new account as parameters.
The only required parameter is the login name of the user, but you probably want to include some additional information ahead of it. Each item of account information is preceded by a single-letter option code with a dash in front of it. The options available with useradd include the following:
Let's create an account for a new user. The user's full name is Sara Green with a login name of sara. To begin, become root user and then type the following command:
# useradd -c "Sara Green" sara
Next, set the initial password for sara using the passwd command. You're prompted to type the password twice:
# passwd sara Changing password for user sara. New password: ******* Retype new password: *******
In creating the account for Sara, the useradd command performs several actions:
The preceding example uses only a few of the available useradd options. Most account settings are assigned using default values. You can set more values explicitly, if you want to. Here's an example that uses a few more options to do so:
# useradd -g users -G wheel,apache -s /bin/tcsh -c "Sara Green" sara
In this case, useradd is told to make users the primary group sara belongs to (-g), add her to the wheel and apache groups, and assign tcsh as her primary command shell (-s). A home directory in /home under the user's name (/home/sara) is created by default. This command line results in a line similar to the following being added to the /etc/passwd file:
sara:x:502:507:Sara Green:/home/sara:/bin/tcsh
Each line in the /etc/passwd file represents a single user account record. Each field is separated from the next by a colon (:) character. The field's position in the sequence determines what it is. As you can see, the login name is first. The password field contains an x because, in this example, the shadow password file is used to store encrypted password data (in /etc/shadow).
The user ID selected by useradd is 502. The primary group ID is 507, which corresponds to a private sara group in the /etc/group file. The comment field was correctly set to Sara Green, the home directory was automatically assigned as /home/sara, and the command shell was assigned as /bin/tcsh, exactly as specified with the useradd options.
By leaving out many of the options (as I did in the first useradd example), defaults are assigned in most cases. For example, by not using -g sales or -G wheel,apache, the group name mary was assigned to the new user. Some Linux systems (other than Fedora and RHEL) assign users as the group name by default. Likewise, excluding -s /bin/tcsh causes /bin/bash to be assigned as the default shell.
The /etc/group file holds information about the different groups on your Linux system and the users who belong to them. Groups are useful for enabling multiple users to share access to the same files while denying access to others. Here is the /etc/group entry created for sara:
sara:x:507:
Each line in the group file contains the name of a group, a group password (usually filled with an x), the group ID number associated with it, and a list of users in that group. By default, each user is added to his or her own group, beginning with the next available GID, starting with 500.
The useradd command determines the default values for new accounts by reading the /etc/login.defs and /etc/default/useradd files. You can modify those defaults by editing the files manually with a standard text editor. Although login.defs is different on different Linux systems, the following is an example containing many of the settings you might find in a login.defs file:
PASS_MAX_DAYS 99999 PASS_MIN_DAYS 0 PASS_MIN_LEN 5 PASS_WARN_AGE 7 UID_MIN 500 UID_MAX 60000 GID_MIN 500 GID_MAX 60000 CREATE_HOME yes
All uncommented lines contain keyword/value pairs. For example, the keyword PASS_MIN_LEN is followed by some whitespace and the value 5. This tells useradd that the user password must be at least five characters. Other lines enable you to customize the valid range of automatically assigned user ID numbers or group ID numbers. (Fedora starts at UID 500; earlier systems started with UID 100.) A comment section that explains that keyword's purpose precedes each keyword (which I edited out here to save space). Altering a default value is as simple as editing the value associated with a keyword and then saving the file before running the useradd command.
If you want to view other default settings, you can find them in the /etc/default/useradd file. Another way to see default settings is to type the useradd command with the -D option, as follows:
# useradd -D GROUP=100 HOME=/home INACTIVE=-1 EXPIRE= SHELL=/bin/bash SKEL=/etc/skel
You can also use the -D option to change defaults. When run with this flag, useradd refrains from actually creating a new user account; instead, it saves any additionally supplied options as the new default values in /etc/default/useradd. Not all useradd options can be used in conjunction with the -D option. You can use only the five options listed next.
To set any of the defaults, give the -D option first, and then add the defaults you want to set. For example, to set the default home directory location to /home/everyone and the default shell to /bin/tcsh, type the following:
# useradd -D -b /home/everyone -s /bin/tcsh
In addition to setting up user defaults, an administrator can create default files that are copied to each user's home directory for use. These files can include login scripts and shell configuration files (such as .bashrc).
Other commands that are useful for working with user accounts include usermod (to modify settings for an existing account) and userdel (to delete an existing user account).
The usermod command provides a simple and straightforward method for changing account parameters. Many of the options available with it mirror those found in useradd. The options that can be used with this command include the following:
The following are examples of the usermod command:
# usermod -s /bin/csh chris # usermod -Ga sales,marketing, chris
The first example changes the shell to the csh shell for the user named chris. In the second example, supplementary groups are added for the user chris. The -a option (-Ga) makes sure that the supplementary groups are added to any existing groups for the user chris. If the -a is not used, existing supplementary groups for chris are erased and the new list of groups includes the only supplementary groups assigned to that user.
Just as usermod is used to modify user settings and useradd is used to create users, userdel is used to remove users. The following command removes the user chris:
# userdel -r chris
Here, the user chris is removed from the /etc/password file. The –r option removes the user's home directory as well. If you choose not to use –r, as follows, the home directory for chris is not removed:
# userdel chris
Keep in mind that simply removing the user account does not change anything about the files that user leaves around the system (except those that are deleted when you use -r). However, ownership of files left behind appears as belonging to the previous owner's user ID number when you run ls -l on the files.
Before you delete the user, you may want to run a find command to find all files that would be left behind by the user. After you delete the user, you could search on user ID to find files left behind. Here are two find commands to do those things:
# find / -user chris -ls # find / -uid 504 -ls
Because files that are not assigned to any username are considered to be a security risk, it is a good idea to find those files and assign them to a real user account. Here's an example of a find command that finds all files in the file system that are not associated with any user (the files are listed by UID):
# find / -nouser -ls
Group accounts are useful if you want to share a set of files with multiple users. You can create a group and change the set of files to be associated with that group. The root user can assign users to that group so they can have access to files based on that group's permission. Consider the following file and directory:
$ ls -ld /var/salesdocs /var/salesdocs/file.txt drwxrwxr-x. 2 root sales 4096 Jan 14 09:32 /var/salesstuff/ -rw-rw-r--. 1 root sales 0 Jan 14 09:32 /var/salesstuff/file.txt
Looking at permissions on the directory /var/salesdocs (rwxrwxr-x), you see the second set of rwx shows that any member of the group (sales) has permission to read files in that directory (r is read), create and delete files from that directory (w is write), and change to that directory (x is execute). The file named file.txt can be read and changed by members of the sales group (based on the second rw-).
Every user is assigned to a primary group. In Fedora and RHEL, by default, that group is a new group with the same name as the user. So if the user were named sara, the group assigned to her would also be sara. The primary group is indicated by the number in the third field of each entry in the /etc/passwd file, for example, the group ID 507 here:
sara:x:502:507:Sara Green:/home/sara:/bin/tcsh
That entry points to an entry in the /etc/group file:
sara:x:507:
Let's turn to the sara user and group accounts for examples. Here are a few facts about using groups:
sales:x:302:joe,bill,sally,sara marketing:x:303:mike,terry,sara
[sara]$ touch file1 [sara]$ newgrp sales [sara]$ touch file2 [sara]$ ls -l file* -rw-rw-r--. 1 sara sara 0 Jan 18 22:22 file1 -rw-rw-r--. 1 sara sales 0 Jan 18 22:23 file2 [sara]$ exit
It is also possible to allow users to temporarily become a member of a group with the newgrp command without actually being a member of that group. To do that, someone with root permission can use gpasswd to set a group password (such as gpasswd sales). After that, any user can type newgrp sales into a shell and temporarily use sales as their primary group by simply entering the group password when prompted.
As the root user, you can create new groups from the User Manager window or from the command line with the groupadd command. Also, as noted earlier, groups are created automatically when a user account is created.
Group ID numbers from 0 through 499 are assigned to special administrative groups. For example, the root group is associated with GID 0. Regular groups begin at 500 for Red Hat Enterprise Linux and Fedora. On the first UNIX systems, GIDs went from 0 to 99. Other Linux systems reserve GIDs between 0 to 1,000 for administrative groups.
Here are some examples of creating a group account with the groupadd command:
# groupadd kings # groupadd -g 325 jokers
In the examples just shown, the group named kings is created with the next available group ID. After that, the group jokers is created using the 325 group ID. Some administrators like using an undefined group number under 500 so the group they create doesn't intrude on the group designations above 500 (so UID and GID numbers can go along in parallel).
To change a group later, use the groupmod command. For example:
# groupmod -g 330 jokers # groupmod -n jacks jokers
In the first example, the group ID for jokers is changed to 330. In the second, the name jokers is changed to jacks. If you wanted to then assign any of the groups as supplementary groups to a user, you can use the usermod command (as described earlier in this chapter).
The basic Linux method of handling user and group accounts has not changed since the first UNIX systems were developed decades ago. However, as Linux systems have become used in more complex ways, features for managing users, groups, and the permissions associated with them have been added on to the basic user/group model so that it could be:
The following sections describe how to use features such as Access Control Lists (ACLs) and shared directories (sticky bit and set GID bit directories) to provide powerful ways to selectively share files and directories. Next, I describe how to manage user accounts from centralized authentication servers using the Authentication Configuration window.
The Access Control List (ACL) feature was created so that regular users could share their files and directories selectively with other users and groups. With ACLs, a user can allow others to read, write, and execute files and directories without leaving those file system elements wide open or requiring the root user to change the user or group assigned to them.
Here are a few things to know about ACLs:
Using the setfacl command, you can modify permissions (-m) or remove ACL permissions (-x). The following is an example of the syntax of the setfacl command:
setfacl -m u:username:rwx filename
In the example just shown, the modify option (-m) is followed by the letter u, indicating that you are setting ACL permissions for a user. After a colon (:), you indicate the username, followed by another colon and the permissions you want to assign. As with the chmod command, you can assign read (r), write (w), and/or execute (x) permissions to the user or group (in the example, full rwx permission is given). The last argument is replaced by the actual filename you are modifying.
The following are some examples of the user mary using the setfacl command to add permission for other users and groups on a file:
[mary]$ touch /tmp/memo.txt [mary]$ ls -l /tmp/memo.txt -rw-rw-r--. 1 mary mary 0 Jan 21 09:27 /tmp/memo.txt [mary]$ setfacl -m u:bill:rw /tmp/memo.txt [mary]$ setfacl -m g:sales:rw /tmp/memo.txt
In the preceding example, mary created a file named /tmp/memo.txt. Using the setfacl command, she modified (-m) permissions for the user named bill so that he now has read/write (rw) permissions to that file. Then she modified permissions for the group sales so anyone belonging to that group would also have read/write permissions. Look at ls -l and getfacl output on that file now:
[mary]$ ls -l /tmp/memo.txt -rw-rw-r--+ 1 mary mary 0 Jan 21 09:27 /tmp/memo.txt [mary]$ getfacl /tmp/memo.txt # file: tmp/memo.txt # owner: mary # group: mary user::rw- user:bill:rw- group::rw- group:sales:rw- mask::rw- other::r--
From the ls -l output, notice the plus sign (+) in the rw-rw-r--+ output. The plus sign indicates that ACLs are set on the file, so you know to run the getfacl command to see how ACLs are set. The output shows mary as owner and group (same as what you see with ls -l), the regular user permissions (rw-), and permissions for ACL user bill (rw-). The same is true for group permissions and permissions for the group sales. Other permissions are r--.
The mask line (near the end of the previous getfacl example) requires some special discussion. As soon as you set ACLs on a file, the regular group permission on the file sets a mask of the maximum permission an ACL user or group can have on a file. So, even if you provide an individual with more ACL permissions than the group permissions will allow, the individual's effective permissions will not exceed the group permissions. For example:
]
[mary]$ chmod 644 /tmp/memo.txt [mary]$ getfacl /tmp/memo.txt # file: tmp/memo.txt # owner: mary # group: mary user::rw- user:bill:rw- #effective:r-- group::rw- #effective:r-- group:sales:rw- #effective:r-- mask::r-- other::r--
Notice in the preceding example that even though the user bill and group sales have rw- permissions, their effective permissions are r--. So, bill or anyone in sales would not be able to change the file unless mary were to open permissions again (for example, by typing chmod 664 /tmp/memo.txt).
Setting default ACLs on a directory enables your ACLs to be inherited. That means that when new files and directories are created in that directory, they are assigned the same ACLs. To set a user or group ACL permission as the default, you add a d: to the user or group designation. Consider the following example:
[mary]$ mkdir /tmp/mary [mary]$ setfacl -m d:g:market:rwx /tmp/mary/ [mary]$ getfacl /tmp/mary/ # file: tmp/mary/ # owner: mary # group: mary user::rwx group::rwx other::r-x default:user::rwx default:group::rwx default:group:sales:rwx default:group:market:rwx default:mask::rwx default:other::r-x
To make sure that the default ACL worked, create a subdirectory. Then run getfacl again. You will see that default lines are added for user, group, mask, and other, which are inherited from the directory's ACLs.
[mary]$ mkdir /tmp/mary/test [mary]$ getfacl /tmp/mary/test # file: tmp/mary/test # owner: mary # group: mary user::rwx group::rwx group:sales:rwx group:market:rwx mask::rwx other::r-x default:user::rwx default:group::rwx default:group:sales:rwx default:group:market:rwx default:mask::rwx default:other::r-x
Notice that when you create a file in that directory, the inherited permissions are different. Because a regular file is created without execute permission, the effective permission is reduced to rw-:
[mary@cnegus ∼]$ touch /tmp/mary/file.txt [mary@cnegus ∼]$ getfacl /tmp/mary/file.txt # file: tmp/mary/file.txt # owner: mary # group: mary user::rw- group::rwx #effective:rw- group:sales:rwx #effective:rw- group:market:rwx #effective:rw- mask::rw- other::r--
Basic Linux file systems have only one user and one group assigned to each file and directory and do not include ACL support by default. Linux ext file system types (ext2, ext3, and ext4) can add ACL support through a mount option. To add ACL support, you must add the acl mount option when you mount it. You can do that in any of several ways:
Keep in mind that in Fedora and Red Hat Enterprise Linux systems, you only have to add the acl mount option to those file systems you create after Linux is installed. The anaconda installer automatically adds ACL support to every file system it creates during install time. To check that the acl option has been added to a file system, determine the device name associated with the file system, and then run the tune2fs -l command to view the implanted mount options. For example:
# mount | grep home /dev/mapper/mybox-home on /home type ext4 (rw) # tune2fs -l /dev/mapper/mybox-home | grep "mount options" Default mount options: user_xattr acl
First, I typed the mount command to see a list of all file systems that are currently mounted, limiting the output by grepping for the word home (because I was looking for the file system mounted on /home). Once I saw the file system's device name, I used it as an option to tune2fs -l to find the default mount options line. There, I could see that mount options user_xattr (for extended attributes such as SELinux) and acl were both implanted in the file system super block so they would be used when the file system was mounted.
If the Default mount options field is blank (such as when you have just created a new file system), you can add the acl mount option using the tune2fs -o command. For example, I created a file system on a removable USB drive that was assigned as the /dev/sdc1 device. To implant the acl mount option and check that it is there, I ran the following commands:
# tune2fs -o acl /dev/sdc1 # tune2fs -l /dev/sdc1 | grep "mount options" Default mount options: acl
You can test that this worked by remounting the file system and trying to use the setfacl command on a file in that file system.
A second way to add acl support to a file system is to add the acl option to the line in the /etc/fstab file that automatically mounts the file system at boot time. The following is an example of what a line would look like that mounts the ext4 file system located on the /dev/sdc1 device to the /var/stuff directory:
/dev/sdc1 /var/stuff ext4 acl 1 2
Instead of the defaults entry in the fourth field, I added acl. If there were already options set in that field, add a comma after the last option and add acl. The next time the file system is mounted, ACLs are enabled. If the file system were already mounted, I could type the following mount command as root to remount the file system, using acl or any other values added to the /etc/fstab file:
# mount -o remount /dev/sdc1
A third way you can add ACL support to a file system is to mount the file system by hand and specifically request the acl mount option. So, if there were no entry for the file system in the /etc/fstab file, after creating the mount point (/var/stuff), type the following command to mount the file system and include ACL support:
# mount -o acl /dev/sdc1 /var/stuff
Keep in mind that the mount command only mounts the file system temporarily. When the system reboots, the file system will not be mounted again, unless you add an entry to the /etc/fstab file.
There is a special set of three permission bits that are typically ignored when you use the chmod command to change permissions on the file system. These bits can set special permissions on commands and directories. The focus of this section is setting the bits that help you create directories to use for collaboration.
As with read, write, and execute bits for user, group, and other, these special file permission bits can be set with the chmod command. If, for example, you run chmod 775 /mnt/xyz, the implied permission is actually 0775. To change permissions, you can replace the number 0 with any combination of those three bits (4, 2, and 1), or you can use letter values instead. (Refer to Chapter 4, “Moving Around the Filesystem,” if you need to be reminded about how permisisons work.) The letters and numbers are shown in Table 11.1.
Name | Numeric value | Letter value |
Set user ID bit | 4 | u+s |
Set group ID bit | 2 | g+s |
Sticky bit | 1 | o+t |
The bits you are interested in for creating collaborative directories are the set group ID bit (2) and sticky bit (1). If you are interested in other uses of the set user ID and set group ID bits, refer to the sidebar “Using Set UID and Set GID Bit Commands.”
By creating a set GID directory, any files created in that directory are assigned to the group assigned to the directory itself. The idea is to have a directory where all members of a group can share files but still protect them from other users. Here's a set of steps for creating a collaborative directory for all users in the group I created called sales:
# groupadd -g 301 sales
# usermod -aG sales mary
# mkdir /mnt/salestools
$ ls /bin/su -rwsr-xr-x. 1 root root 30092 Jan 30 07:11 su
# chgrp sales /mnt/salestools
# chmod 2775 /mnt/salestools
# su - mary [mary]$ touch /mnt/salestools/test.txt [mary]$ ls -ld /mnt/salestools/ /mnt/salestools/test.txt drwxrwsr-x. 2 root sales 4096 Jan 22 14:32 /mnt/salestools/ -rw-rw-r--. 1 mary sales 0 Jan 22 14:32 /mnt/salestools/test.txt
Typically, a file created by mary would have the group mary assigned to it. But because test.txt was created in a set group ID bit directory, the file is assigned to the sales group. Now, anyone that belongs to the sales group can read or write that file, based on group permissions.
A restricted deletion directory is created by turning on a directory's sticky bit. What makes a restricted deletion directory different than other directories? Normally, if write permission is open to a user on a file or directory, that user is able to delete that file or directory. However, in a restricted deletion directory, unless you are the root user or the owner of the directory, you can never delete another user's files.
Typically, a restricted deletion directory is used as a place where lots of different users can create files. For example, the /tmp directory is a restricted deletion directory:
$ ls -ld /tmp drwxrwxrwt. 116 root root 36864 Jan 22 14:18 /tmp
You can see the permissions are wide open, but instead of an x for the execute bit for other, the t indicates that the sticky bit is set. The following is an example of creating a restricted deletion directory with a file that is wide open for writing by anyone:
[mary]$ mkdir /tmp/mystuff [mary]$ chmod 1777 /tmp/mystuff [mary]$ cp /etc/services /tmp/mystuff/ [mary]$ chmod 666 /tmp/mystuff/services [mary]$ ls -ld /tmp/mystuff /tmp/mystuff/services drwxrwxrwt. 2 mary mary 4096 Jan 22 15:28 /tmp/mystuff/ -rw-rw-rw-. 1 mary mary 640999 Jan 22 15:28 /tmp/mystuff/services
With permissions set to 1777 on the /tmp/mystuff directory, you can see that all permissions are wide open, but a t appears instead of the last execute bit. With the /tmp/mystuff/services file open for writing, any user could open it and change its contents. However, because the file is in a sticky bit directory, only root and mary can delete that file.
Although the default way of authenticating users in Linux is to check user information against the /etc/passwd file and passwords from the /etc/shadow file, there are other ways to do authentication as well. In most large enterprises, user account information is stored in a centralized authentication server, so each time you install a new Linux system, instead of adding user accounts to that system, you have the Linux system query the authentication server when someone tries to log in.
As with local passwd/shadow authentication, configuring centralized authentication requires that you provide two types of information: account information (username, user/group IDs, home directory, default shell, and so on) and authentication method (different types of encrypted passwords, smart cards, retinal scans, and so on). Linux provides ways of configuring those types of information.
Because I hope you will someday use your Linux skills to work in a large Linux installation, I want to introduce the concept of centralized authentication. For now, I will just discuss how to connect to existing authentication servers (rather than set up those servers themselves) and have users of a Linux system you configure authenticate against those types of servers.
In Fedora and Red Hat Enterprise Linux, there is a graphical window for configuring centralized authentication called the Authentication Configuration window. Through that window, you can configure where your system gets account information and what type of authentication method is used to verify users. Supported centralized database types include:
For this introduction to configuring centralized authentication servers, you will configure a Linux system to authenticate against an LDAP server, using the Authentication Configuration window in Red Hat Enterprise Linux.
To begin, you need to gather information about the LDAP service at your location. That includes information about the account database and the authentication method:
To start the Authentication Configuration window from a Red Hat Enterprise Linux 6 desktop, select System ⇒ Administration ⇒ Authentication. For a default system that only does local (passwd/shadow) authentication, the window appears.
To add LDAP authentication, select the User Account Database box and select LDAP. Then fill in the information described in the preceding bullet points.
If the new authentication method is configured properly, you should be able to go to a shell and validate that. If you know of a user account available from the LDAP server, use the following getent command to check that the account is available:
# getent passwd jsmith jsmith:x:13599:13600:John Smith:/home/jsmith:/bin/bash
If you see the account information, then you know your system was able to retrieve it from the LDAP server. The next thing to check is that the authentication method is working as well. For that, you could try to log in as the user from the console or by using the ssh command. For example:
$ ssh jsmith@localhost
When prompted, enter the username and password. If it succeeds, you know that both the account and authentication information you entered for your LDAP server were correct.
With your authentication centralized, consider centralizing your users' home directories as well. Using the Linux automounter (autofs service), you could set up home directories that are automatically mounted when each user logs in, regardless of which machine they are logging into. (See Chapter 20, “Configuring an NFS File Server,” for information on setting up an NFS server and configuring clients to automount from that server.)
Having separate user accounts is the primary method of setting secure boundaries between the people who use your Linux system. Regular users typically can control the files and directories within their own home directories, but very little outside of those directories.
In this chapter, you learned how to add user and group accounts, how to modify them, and even how to extend user and group accounts beyond the boundaries of the local /etc/password file. You also learned that authentication can be done by accessing centralized LDAP servers.
The next chapter introduces another basic topic needed by Linux system administrators: how to manage disks. In that chapter, you learn how to partition disks, add filesystems, and mount them, so the contents of the disk partitions are accessible to those using your system.
Use these exercises to test your knowledge of adding and managing user and group accounts in Linux. These tasks assume you are running a Fedora or Red Hat Enterprise Linux system (although some tasks will work on other Linux systems as well). If you are stuck, solutions to the tasks are shown in Appendix B (although in Linux, there are often multiple ways to complete a task).