Linux User and Group Management Chapter 6 PDF

Chapter 6. Manage Local Users and Groups Describe User and Group Concepts Objectives Describe the purpose of users and groups on a Linux system. What Is a User? A user account provides security boundaries between people and programs that can run commands. Users have usernames to identi...

Chapter 6. Manage Local Users and Groups Describe User and Group Concepts Objectives Describe the purpose of users and groups on a Linux system. What Is a User? A user account provides security boundaries between people and programs that can run commands. Users have usernames to identify them to human users and for ease of working. Internally, the system distinguishes user accounts by the unique identification number, the user ID or UID, which is assigned to them. In most scenarios, if a human uses a user account, then the system assigns a secret password for the user to prove that they are the authorized user to log in. User accounts are fundamental to system security. Every process (running program) on the system runs as a particular user. Every file has a particular user as its owner. With file ownership, the system enforces access control for users of the files. The user that is associated with a running process determines the files and directories that are accessible to that process. User accounts are of the following main types: the superuser, system users, and regular users. The superuser account administers the system. The superuser name is root and the account has a UID of 0. The superuser has full system access. The system user accounts are used by processes that provide supporting services. These processes, or daemons, usually do not need to run as the superuser. They are assigned non-privileged accounts to secure their files and other resources from each other and from regular users on the system. Users do not interactively log in with a system user account. Most users have regular user accounts for their day-to-day work. Like system users, regular users have limited access to the system. Use the id command to show information about the currently logged-in user: [user01@host ~]$ id uid=1000(user01) gid=1000(user01) groups=1000(user01) context=unconfined_u:unconfined _r:unconfined_t:s0-s0:c0.c1023 To view information about another user, pass the username to the id command as an argument: [user01@host ~]$ id user02 uid=1002(user02) gid=1001(user02) groups=1001(user02) context=unconfined_u:unconfined _r:unconfined_t:s0-s0:c0.c1023 Use the ls -l command to view the owner of a file. Use the ls -ld command to view the owner of a directory, rather than the contents of that directory. In the following output, the third column shows the username. [user01@host ~]$ ls -l mytextfile.txt -rw-rw-r--. 1 user01 user01 0 Feb 5 11:10 mytextfile.txt [user01@host]$ ls -ld Documents drwxrwxr-x. 2 user01 user01 6 Feb 5 11:10 Documents Use the ps command to view process information. The default is to show only processes in the current shell. Use the ps command -a option to view all processes with a terminal. Use the ps command -u option to view the user that is associated with a process. In the following output, the first column shows the username. [user01@host ~]$ ps -au USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1690 0.0 0.0 220984 1052 ttyS0 Ss+ 22:43 0:00 /sbin/agetty -o -p -- \u --keep-baud 1 user01 1769 0.0 0.1 377700 6844 tty2 Ssl+ 22:45 0:00 /usr/libexec/gdm-x-sessio n --register- user01 1773 1.3 1.3 528948 78356 tty2 Sl+ 22:45 0:03 /usr/libexec/Xorg vt2 -di splayfd 3 -au user01 1800 0.0 0.3 521412 19824 tty2 Sl+ 22:45 0:00 /usr/libexec/gnome-sessio n-binary user01 3072 0.0 0.0 224152 5756 pts/1 Ss 22:48 0:00 -bash user01 3122 0.0 0.0 225556 3652 pts/1 R+ 22:49 0:00 ps -au The output of the preceding command displays users by name, but internally the operating system uses UIDs to track users. The mapping of usernames to UIDs is defined in databases of account information. By default, systems use the /etc/passwd file to store information about local users. Each line in the /etc/passwd file contains information about one user. The file is divided into seven colon-separated fields. An example of a line from /etc/passwd follows: [user01@host ~]$ cat /etc/passwd...output omitted... user01:x:1000:1000:User One:/home/user01:/bin/bash Consider each part of the code block, separated by a colon: user01 : The username for this user. x : The user's encrypted password was historically stored here; it is now a placeholder. 1000 : The UID number for this user account. 1000 : The GID number for this user account's primary group. Groups are discussed later in this section. User One : A brief comment, description, or the real name for this user. /home/user01 : The user's home directory, and the initial working directory when the login shell starts. /bin/bash : The default shell program for this user that runs at login. Some accounts use the /sbin/nologin shell to disallow interactive logins with that account. What Is a Group? A group is a collection of users that need to share access to files and other system resources. Groups can grant access to files to a set of users instead of to a single user. Like users, groups have group names for easier recognition. Internally, the system distinguishes groups by the unique identification number, the group ID or GID, which is assigned to them. The mapping of group names to GIDs is defined in identity management databases of group account information. By default, systems use the /etc/group file to store information about local groups. Each line in the /etc/group file contains information about one group. Each group entry is divided into four colon-separated fields. An example of a line from /etc/group follows: [user01@host ~]$ cat /etc/group...output omitted... group01:x:10000:user01,user02,user03 Consider each part of the code block, separated by a colon: group01 : Name for this group. x : Obsolete group password field; it is now a placeholder. 10000 : The GID number for this group (10000). user01,user02,user03 : A list of users that are members of this group as a supplementary group. Primary Groups and Supplementary Groups Every user has exactly one primary group. For local users, this group is listed by GID in the /etc/passwd file. The primary group owns files that the user creates. When a regular user is created, a group is created with the same name as the user, to be the primary group for the user. The user is the only member of this User Private Group. This group membership design simplifies the management of file permissions, to have user groups separated by default. Users might also have supplementary groups. Membership in supplementary groups is stored in the /etc/group file. Users are granted access to files based on whether any of their groups have access, regardless of whether the groups are primary or supplementary. For example, if the user01 user has a user01 primary group and wheel and webadmin supplementary groups, then that user can read files that any of those three groups can read. The id command can show group membership for a user. In the following example, the user01 user has the user01 group as their primary group (gid). The groups item lists all group memberships for this user, and the user also has the wheel and group01 groups as supplementary groups. [user01@host ~]$ id uid=1001(user01) gid=1003(user01) groups=1003(user01),10(wheel),10000(group01) contex t=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 Gain Superuser Access Objectives Switch to the superuser account to manage a Linux system, and grant other users superuser access through the sudo command. The Superuser Most operating systems have a superuser that has all power over the system. In Red Hat Enterprise Linux, it is the root user. This user has the power to override normal privileges on the file system, and you can use it to manage and administer the system. For tasks such as installing or removing software, and to manage system files and directories, users must escalate their privileges to the root user. Usually, only the root user can control most devices, but some exceptions apply. Normal users can control removable devices, such as USB devices. Thus, normal users can add and remove files and otherwise manage a removable device, but only root can manage hard drives by default. This unlimited privilege, however, comes with responsibility. The root user has unlimited power to damage the system: remove files and directories, remove user accounts, add back doors, and so on. If the root user account is compromised, then the system is in danger and you might lose administrative control. Red Hat encourages system administrators to log in always as a normal user, and to escalate privileges to root only when needed. The root account on Linux is similar to the local Administrator account on Microsoft Windows. In Linux, most system administrators log in to the system as an unprivileged user and use various tools to temporarily gain root privileges. Switch User Accounts With the su command, users can switch to a different user account. If you run the su command from a regular user account with another user account as a parameter, then you must provide the password of the account to switch to. When the root user runs the su command, you do not need to enter the user's password. This example uses the su command from the user01 account to switch to the user02 account: [user01@host ~]$ su - user02 Password: user02_password [user02@host ~]$ If you omit the username, then the su or su - command attempts to switch to root by default. [user01@host ~]$ su - Password: root_password [root@host ~]# The su command starts a non-login shell, whereas the su - command (with the dash option) starts a login shell. The main distinction between the two commands is that su - sets up the shell environment as if it is a new login as that user, whereas su starts a shell as that user, but uses the original user's environment settings. Usually, administrators should run su - to get a shell with the target user's normal environment settings. For more information, see the bash(1) man page. NOTE The most frequent use for the su command is to get a command-line interface (shell prompt) that runs as another user, typically the root user. However, you can use the su command -c option to run an arbitrary program as another user. This behavior is similar to the Windows runas utility. Run info su to view more details. Run Commands with Sudo For security reasons, in some cases system administrators configure the root user not to have a valid password. Thus, users cannot log in to the system as root directly with a password. Moreover, you cannot use su to get an interactive shell. In this case, you can use the sudo command to get root access. Unlike the su command, sudo normally requires users to enter their own password for authentication, not the password of the user account that they are trying to access. That is, users who use the sudo command to run commands as root do not need to know the root password. Instead, they use their own passwords to authenticate access. The next table summarizes the differences between the su, su -, and sudo commands: su su - sudo Become new user Yes Yes Per escalated command Environment Current user's New user's Current user's Password required New user's New user's Current user's Privileges Same as new user Same as new user Defined by configuration Activity logged su command only su command only Per escalated command Additionally, you can configure the sudo command to allow specific users to run any command as some other user, or only some commands as that user. For example, if you configure the sudo command to allow the user01 user to run the usermod command as root, then you can run the following command to lock or unlock a user account: [user01@host ~]$ sudo usermod -L user02 [sudo] password for user01: user01_password [user01@host ~]$ su - user02 Password: user02_password su: Authentication failure [user01@host ~]$ If a user tries to run a command as another user, and the sudo configuration does not permit it, then bash blocks the command, logs the attempt, and sends by default an email to the root user. [user02@host ~]$ sudo tail /var/log/secure [sudo] password for user02: user02_password user02 is not in the sudoers file. This incident will be reported. [user02@host ~]$ Another benefit of sudo is to log by default all the executed commands to /var/log/secure. [user01@host ~]$ sudo tail /var/log/secure...output omitted... Mar 9 20:45:46 host sudo: user01 : TTY=pts/0 ; PWD=/home/user01 ; USER=root ; COMMAND=/sbin/usermod -L user02...output omitted... In Red Hat Enterprise Linux 7 and later versions, all members of the wheel group can use sudo to run commands as any user, including root, by using their own password. Get an Interactive Root Shell with Sudo To access the root account with sudo, use the sudo -i command. This command switches to the root account and runs that user's default shell (usually bash) and associated interactive login scripts. To run the shell without the interactive scripts, use the sudo -s command. For example, an administrator can get an interactive shell as root on an AWS Elastic Cloud Computing (EC2) instance by using SSH public-key authentication to log in as the ec2-user normal user. Then run the sudo -i command to access the root user's shell. [ec2-user@host ~]$ sudo -i [sudo] password for ec2-user: ec2-user_password [root@host ~]# Configure sudo The /etc/sudoers file is the main configuration file for the sudo command. To avoid problems if multiple administrators try to edit the file at the same time, you can edit it only with the special visudo command. The visudo editor also validates the file, to ensure no syntax errors. For example, the following line from the /etc/sudoers file enables sudo access for wheel group members: %wheel ALL=(ALL:ALL) ALL The %wheel string is the user or group that the rule applies to. The % symbol before the wheel word specifies a group. The ALL=(ALL:ALL) command specifies that on any host with this file (the first ALL), users in the wheel group can run commands as any other user (the second ALL) and as any other group (the third ALL) on the system. The final ALL command specifies that users in the wheel group can run any command. By default, the /etc/sudoers file also includes the contents of any files in the /etc/sudoers.d directory as part of the configuration file. With this hierarchy, you can add sudo access for a user by putting an appropriate file in that directory. NOTE You can enable or disable sudo access by copying a file into the directory or removing it from the directory. In this course, you create and remove files in the /etc/sudoers.d directory to configure sudo access for users and groups. To enable full sudo access for the user01 user, you can create the /etc/sudoers.d/user01 file with the following content: user01 ALL=(ALL) ALL To enable full sudo access for the group01 group, you can create the /etc/sudoers.d/group01 file with the following content: %group01 ALL=(ALL) ALL To enable users in the games group to run the id command as the operator user, you can create the /etc/sudoers.d/games file with the following content: %games ALL=(operator) /bin/id You can also set up sudo to allow a user to run commands as another user without entering their password, by using the NOPASSWD: ALL command: ansible ALL=(ALL) NOPASSWD: ALL Although obvious security risks apply to granting this level of access to a user or group, system administrators often use this approach with cloud instances, virtual machines, and provisioning systems for configuring servers. You must protect the account with this access and require SSH public-key authentication for a user on a remote system to access it at all. For example, the official Amazon Machine Image (AMI) for Red Hat Enterprise Linux in the Amazon Web Services Marketplace ships with the root and the ec2- user passwords locked. The ec2-user account is set up to allow remote interactive access through SSH public-key authentication. The ec2-user user can also run any command as root without a password, because the last line of the AMI's /etc/sudoers file is set up as follows: ec2-user ALL=(ALL) NOPASSWD: ALL You can re-enable the requirement to enter a password for sudo, or introduce other changes to tighten security as part of the system configuration. Guided Exercise: Gain Superuser Access Practice switching to the root account and running commands as root. Outcomes  Use the sudo command to switch to the root user and access the interactive shell as root without knowing the password of the superuser. Explain how the su and su - commands affect the shell environment through running or not running the login scripts. Use the sudo command to run other commands as the root user. As the student user on the workstation machine, use the lab command to prepare your system for this exercise. This command prepares your environment and ensures that all required resources are available. [student@workstation ~]$ lab start users-superuser Instructions 1. From workstation, open an SSH session to servera as the student user. 2. [student@workstation ~]$ ssh student@servera 3....output omitted... [student@servera ~]$ 4. Explore the shell environment of the student user. View the current user and group information and display the current working directory. Also view the environment variables that specify the user's home directory and the locations of the user's executable files. 1. Run id to view the current user and group information. 2. [student@servera ~]$ id uid=1000(student) gid=1000(student) groups=1000(student),10(wheel) co ntext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 3. Run pwd to display the current working directory. 4. [student@servera ~]$ pwd /home/student  5. Print the values of the HOME and PATH variables to determine the home directory and user executables' path, respectively. 6. [student@servera ~]$ echo $HOME 7. /home/student 8. [student@servera ~]$ echo $PATH /home/student/.local/bin:/home/student/bin:/usr/local/bin:/usr/bin:/u sr/local/sbin:/usr/sbin 5. Switch to the root user in a non-login shell and explore the new shell environment. 1. Run the sudo su command at the shell prompt to become the root user. 2. [student@servera ~]$ sudo su 3. [sudo] password for student: student [root@servera student]# 4. Run id to view the current user and group information. 5. [root@servera student]# id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfine d_r:unconfined_t:s0-s0:c0.c1023 6. Run pwd to display the current working directory. 7. [root@servera student]# pwd /home/student 8. Print the values of the HOME and PATH variables to determine the home directory and user executables' path, respectively. 9. [root@servera student]# echo $HOME 10. /root 11. [root@servera student]# echo $PATH  /root/.local/bin:/root/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/s bin:/usr/local/bin When you use the su command to become the root user, you do not keep the current path of the student user. As you can see in the next step, the path is not the root user path either. What happened? The difference is that you do not run su directly. Instead, you run the su command as the root user by using sudo because you do not have the password of the superuser. The sudo command overrides the PATH variable from the environment for security reasons. Any command that runs after the initial override can still update the PATH variable, as you can see in the following steps. 12. Exit the root user's shell to return to the student user's shell. 13. [root@servera student]# exit 14. exit [student@servera ~]$ 6. Switch to the root user in a login shell and explore the new shell environment. 1. Run the sudo su - command at the shell prompt to become the root user. The sudo command might or might not prompt you for the student password, depending on the time-out period of sudo. The default time-out period is five minutes. If you authenticated to sudo within the last five minutes, then the sudo command does not prompt you for the password. If more than five minutes elapsed since you authenticated to sudo, then you must enter student as the password for authentication to sudo. [student@servera ~]$ sudo su - [root@servera ~]#  Notice the difference in the shell prompt compared to that of sudo su in the preceding step. 2. Run id to view the current user and group information. 3. [root@servera ~]# id uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfine d_r:unconfined_t:s0-s0:c0.c1023 4. Run pwd to display the current working directory. 5. [root@servera ~]# pwd /root 6. Print the values of the HOME and PATH variables to determine the home directory and the user executables' path, respectively. 7. [root@servera ~]# echo $HOME 8. /root 9. [root@servera ~]# echo $PATH /root/.local/bin:/root/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/ usr/bin As in the preceding step, after the sudo command resets the PATH variable from the settings in the student user's shell environment, the su - command runs the shell login scripts for root and sets the PATH variable to yet another value. The su command without the dash (-) option does not have the same behavior. 10. Exit the root user's shell to return to the student user's shell. 11. [root@servera ~]# exit 12. logout [student@servera ~]$ 7. Verify that the operator1 user can run any command as any user by using the sudo command. 8. [student@servera ~]$ sudo cat /etc/sudoers.d/operator1 operator1 ALL=(ALL) ALL 9. Become the operator1 user and view the contents of the /var/log/messages file. Copy the /etc/motd file to /etc/motdOLD. Remove the /etc/motdOLD file. As these operations require administrative rights, use the sudo command to run those commands as the superuser. Do not switch to root by using sudo su or sudo su -. Use redhat as the password of the operator1 user. 1. Switch to the operator1 user. 2. [student@servera ~]$ su - operator1 3. Password: redhat [operator1@servera ~]$ 4. Try to view the last five lines of /var/log/messages without using sudo. It should fail. 5. [operator1@servera ~]$ tail -5 /var/log/messages tail: cannot open '/var/log/messages' for reading: Permission denied 6. Try to view the last five lines of /var/log/messages by using sudo. It should succeed. 7. [operator1@servera ~]$ sudo tail -5 /var/log/messages 8. [sudo] password for operator1: redhat 9. Mar 9 15:53:36 servera su: FAILED SU (to operator1) student on pts/1 10. Mar 9 15:53:51 servera su: FAILED SU (to operator1) student on pts/1 11. Mar 9 15:53:58 servera su: FAILED SU (to operator1) student on pts/1 12. Mar 9 15:54:12 servera su: (to operator1) student on pts/1  Mar 9 15:54:25 servera su: (to operator1) student on pts/1 NOTE The preceding output might differ on your system. 13. Try to copy /etc/motd as /etc/motdOLD without using sudo. It should fail. 14. [operator1@servera ~]$ cp /etc/motd /etc/motdOLD cp: cannot create regular file '/etc/motdOLD': Permission denied 15. Try to copy /etc/motd as /etc/motdOLD by using sudo. It should succeed. 16. [operator1@servera ~]$ sudo cp /etc/motd /etc/motdOLD [operator1@servera ~]$ 17. Try to delete /etc/motdOLD without using sudo. It should fail. 18. [operator1@servera ~]$ rm /etc/motdOLD 19. rm: remove write-protected regular empty file '/etc/motdOLD'? y 20. rm: cannot remove '/etc/motdOLD': Permission denied [operator1@servera ~]$ 21. Try to delete /etc/motdOLD by using sudo. It should succeed. 22. [operator1@servera ~]$ sudo rm /etc/motdOLD [operator1@servera ~]$ 23. Return to the workstation system as the student user. 24. [operator1@servera ~]$ exit 25. logout 26. [student@servera ~]$ exit 27. logout  28. Connection to servera closed. [student@workstation ~]$ Manage Local User Accounts Objectives Create, modify, and delete local user accounts. Manage Local Users You can use command-line tools to manage local user accounts. This section reviews some important tools. Create Users from the Command Line The useradd username command creates a user called username. It sets up the user's home directory and account information, and creates a private group for the user called username. At this point, a valid password is not set for the account, and the user cannot log in until a password is set. The useradd --help command displays the basic options to override the defaults. Usually, you can use the same options with the usermod command to modify an existing user. The /etc/login.defs file sets some default options for user accounts, such as the range of valid UID numbers and default password aging rules. The values in this file affect only newly created user accounts. A change to this file does not affect existing users. In Red Hat Enterprise Linux 9, the useradd command assigns new users the first free UID that is greater than or equal to 1000, unless you explicitly specify a UID by using the -u option. Modify Existing Users from the Command Line The usermod --help command displays the options to modify an account. Some common options are as follows: usermod options: Usage -a, --append Use it with the -G option to add the supplementary groups to the user's current set of group memberships instead of replacing the set of supplementary groups with a new set. -c, --comment Add the COMMENT text to the comment field. COMMENT -d, --home Specify a home directory for the user account. HOME_DIR -g, --gid GROUP Specify the primary group for the user account. -G, --groups Specify a comma-separated list of supplementary groups for the user account. GROUPS -L, --lock Lock the user account. -m, --move-home Move the user's home directory to a new location. You must use it with the - d option. -s, --shell Specify a particular login shell for the user account. SHELL -U, --unlock Unlock the user account. Delete Users from the Command Line The userdel username command removes the username user from /etc/passwd, but leaves the user's home directory intact. The userdel -r username command removes the user from /etc/passwd and deletes the user's home directory. WARNING When you remove a user without specifying the userdel -r option, an unassigned UID now owns the user's files. If you create a user and that user is assigned the deleted user's UID, then the new account owns those files, which is a security risk. Typically, organization security policies disallow deleting user accounts, and instead lock them from being used, to avoid this scenario. The following example demonstrates how this scenario can lead to information leakage: [root@host ~]# useradd user01 [root@host ~]# ls -l /home drwx------. 3 user01 user01 74 Mar 4 15:22 user01 [root@host ~]# userdel user01 [root@host ~]# ls -l /home drwx------. 3 1000 1000 74 Mar 4 15:22 user01 [root@host ~]# useradd -u 1000 user02 [root@host ~]# ls -l /home drwx------. 3 user02 user02 74 Mar 4 15:23 user02 drwx------. 3 user02 user02 74 Mar 4 15:22 user01 Notice that user02 now owns all files that user01 previously owned. The root user can use the find / -nouser -o -nogroup command to find all unowned files and directories. Set Passwords from the Command Line The passwd username command sets the initial password or changes the existing password for the username user. The root user can set a password to any value. The terminal displays a message if the password does not meet the minimum recommended criteria, but then you can retype the new password and the passwd command updates it successfully. [root@host ~]# passwd user01 Changing password for user user01. New password: redhat BAD PASSWORD: The password is shorter than 8 characters Retype new password: redhat passwd: all authentication tokens updated successfully. [root@host ~]# A regular user must choose a password at least eight characters long. Do not use a dictionary word, the username, or the previous password. UID Ranges Red Hat Enterprise Linux uses specific UID numbers and ranges of numbers for specific purposes. UID 0 : The superuser (root) account UID. UID 1-200 : System account UIDs that are statically assigned to system processes. UID 201-999 : UIDs that are assigned to system processes that do not own files on this system. Software that requires an unprivileged UID is dynamically assigned a UID from this available pool. UID 1000+ : The UID range to assign to regular, unprivileged users. NOTE RHEL 6 and earlier versions use UIDs in the range 1-499 for system users and UIDs higher than 500 for regular users. You can change the useradd and groupadd default ranges in the /etc/login.defs file. Guided Exercise: Manage Local User Accounts Create several users on your system and set passwords for those users. Outcomes Configure a Linux system with additional user accounts. As the student user on the workstation machine, use the lab command to prepare your system for this exercise. This command prepares your environment and ensures that all required resources are available. [student@workstation ~]$ lab start users-user Instructions 1. From workstation, open an SSH session to servera as the student user, and switch to the root user. 2. [student@workstation ~]$ ssh student@servera 3....output omitted... 4. [student@servera ~]$ sudo -i 5. [sudo] password for student: student [root@servera ~]# 6. Create the operator1 user and confirm that it exists in the system. 7. [root@servera ~]# useradd operator1 8. [root@servera ~]# tail /etc/passwd 9....output omitted... operator1:x:1002:1002::/home/operator1:/bin/bash 10. Set the password for operator1 to redhat. 11. [root@servera ~]# passwd operator1 12. Changing password for user operator1. 13. New password: redhat 14. BAD PASSWORD: The password is shorter than 8 characters 15. Retype new password: redhat passwd: all authentication tokens updated successfully. 16. Create the additional operator2 and operator3 users. Set their passwords to redhat. 1. Add the operator2 user. Set the password for operator2 to redhat. 2. [root@servera ~]# useradd operator2 3. [root@servera ~]# passwd operator2 4. Changing password for user operator2. 5. New password: redhat 6. BAD PASSWORD: The password is shorter than 8 characters 7. Retype new password: redhat passwd: all authentication tokens updated successfully.  8. Add the operator3 user. Set the password for operator3 to redhat. 9. [root@servera ~]# useradd operator3 10. [root@servera ~]# passwd operator3 11. Changing password for user operator3. 12. New password: redhat 13. BAD PASSWORD: The password is shorter than 8 characters 14. Retype new password: redhat passwd: all authentication tokens updated successfully. 17. Update the operator1 and operator2 user accounts to include the Operator One and Operator Two comments, respectively. Verify that the comments exist for the user accounts. 1. Run the usermod -c command to update the comments of the operator1 user account. [root@servera ~]# usermod -c "Operator One" operator1 2. Run the usermod -c command to update the comments of the operator2 user account. [root@servera ~]# usermod -c "Operator Two" operator2 3. View the /etc/passwd file to confirm that the comments for each of the operator1 and operator2 users exist. 4. [root@servera ~]# tail /etc/passwd 5....output omitted... 6. operator1:x:1002:1002:Operator One:/home/operator1:/bin/bash 7. operator2:x:1003:1003:Operator Two:/home/operator2:/bin/bash operator3:x:1004:1004::/home/operator3:/bin/bash 18. Delete the operator3 user along with any personal data of the user. Confirm that the operator3 does not exist. 1. Remove the operator3 user from the system.  [root@servera ~]# userdel -r operator3 2. Confirm that the operator3 user does not exist. 3. [root@servera ~]# tail /etc/passwd 4....output omitted... 5. operator1:x:1002:1002:Operator One:/home/operator1:/bin/bash operator2:x:1003:1003:Operator Two:/home/operator2:/bin/bash Notice that the preceding output does not display the user account information of operator3. 6. Confirm that the operator3 user home directory does not exist. 7. [root@servera ~]# ls -l /home 8. total 0 9. drwx------. 4 devops devops 90 Mar 3 09:59 devops 10. drwx------. 2 operator1 operator1 62 Mar 9 10:19 operator1 11. drwx------. 2 operator2 operator2 62 Mar 9 10:19 operator2 drwx------. 3 student student 95 Mar 3 09:49 student 12. Exit the root user's shell to return to the student user's shell. 13. [root@servera ~]# exit 14. logout [student@servera ~]$ 15. Log off from the servera machine. 16. [student@servera ~]$ exit 17. logout 18. Connection to servera closed. [student@workstation ~]$ Manage Local Group Accounts Objectives Create, modify, and delete local group accounts. Manage Local Groups Several command-line tools enable group management. Although you can use the Users GUI utility to manage groups, Red Hat recommends that you use command-line tools. Create Groups from the Command Line The groupadd command creates groups. Without options, the groupadd command uses the next available GID from the range that the GID_MIN and GID_MAX variables specify in the /etc/login.defs file. By default, the command assigns a GID value that is greater than any other existing GIDs, even if a lower value becomes available. The groupadd command -g option specifies a GID for the group to use. [root@host ~]# groupadd -g 10000 group01 [root@host ~]# tail /etc/group...output omitted... group01:x:10000: NOTE Because of the automatic creation of user private groups (GID 1000+), some administrators set aside a separate range of GIDs for creating supplementary groups for other purposes. However, this extra management is unnecessary, because a user's UID and primary GID do not need to be the same number. The groupadd command -r option creates system groups. As with normal groups, system groups use a GID from the range of listed valid system GIDs in the /etc/login.defs file. The SYS_GID_MIN and SYS_GID_MAX configuration items in the /etc/login.defs file define the range of system GIDs. [root@host ~]# groupadd -r group02 [root@host ~]# tail /etc/group...output omitted... group01:x:10000: group02:x:988: Modify Existing Groups from the Command Line The groupmod command changes the properties of an existing group. The groupmod command -n option specifies a new name for the group. [root@host ~]# groupmod -n group0022 group02 [root@host ~]# tail /etc/group...output omitted... group0022:x:988: Notice that the group name updates to group0022 from group02. The groupmod command -g option specifies a new GID. [root@host ~]# groupmod -g 20000 group0022 [root@host ~]# tail /etc/group...output omitted... group0022:x:20000: Notice that the GID changes to 20000 from 988. Delete Groups from the Command Line The groupdel command removes groups. [root@host ~]# groupdel group0022 NOTE You cannot remove a group if it is the primary group of an existing user. Similar to using the userdel command, ensure first that you locate files that the group owns. Change Group Membership from the Command Line The membership of a group is controlled with user management. Use the usermod - g command to change a user's primary group. [root@host ~]# id user02 uid=1006(user02) gid=1008(user02) groups=1008(user02) [root@host ~]# usermod -g group01 user02 [root@host ~]# id user02 uid=1006(user02) gid=10000(group01) groups=10000(group01) Use the usermod -aG command to add a user to a supplementary group. [root@host ~]# id user03 uid=1007(user03) gid=1009(user03) groups=1009(user03) [root@host ~]# usermod -aG group01 user03 [root@host ~]# id user03 uid=1007(user03) gid=1009(user03) groups=1009(user03),10000(group01) IMPORTANT The usermod command -a option enables the append mode. Without the -a option, the command removes the user from any of their current supplementary groups that are not included in the -G option's list. Compare Primary and Supplementary Group Membership A user's primary group is the group that is viewed on the user's account in the /etc/passwd file. A user can belong to only one primary group at a time. A user's supplementary groups are the additional groups that are configured for the user and viewed on the user's entry in the /etc/group file. A user can belong to as many supplementary groups as is necessary to implement file access and permissions effectively. For configuring group-based file permissions, no difference exists between a user's primary and supplementary groups. If the user belongs to any group that is assigned access to specific files, then that user has access to those files. The only distinction between a user's primary and supplementary memberships is when a user creates a file. New files must have a user owner and a group owner, which is assigned when the file is created. The user's primary group is used for the new file's group ownership, unless command options override it. Temporarily Change Your Primary Group Only a user's primary group is used for new file creation attributes. However, you can temporarily switch your primary group to a supplementary group that you already belong to. You might switch if you are about to create files, manually or scripted, and want to assign a different group as owner when they are being created. Use the newgrp command to switch your primary group, in this shell session. You can switch between any primary or supplementary group that you belong to, but only one group at a time can be primary. Your primary group returns to the default if you log out and log in again. In this example, the group01 group temporarily becomes this user's primary group. [user03@host ~]# id uid=1007(user03) gid=1009(user03) groups=1009(user03),10000(group01) [user03@host ~]$ newgrp group01 [user03@host ~]# id uid=1007(user03) gid=10000(group01) groups=1009(user03),10000(group01) Guided Exercise: Manage Local Group Accounts Create groups, use them as supplementary groups for some users without changing those users' primary groups, and configure one of the groups with sudo access to run commands as root. Outcomes Create groups and use them as supplementary groups. Configure sudo access for a group. As the student user on the workstation machine, use the lab command to prepare your system for this exercise. This command creates the necessary user accounts to set up the environment correctly. [student@workstation ~]$ lab start users-group Instructions 1. From workstation, open an SSH session to servera as the student user and switch to the root user. 2. [student@workstation ~]$ ssh student@servera 3....output omitted... 4. [student@servera ~]$ sudo -i 5. [sudo] password for student: student [root@servera ~]# 6. Create the operators supplementary group with a GID of 30000. [root@servera ~]# groupadd -g 30000 operators 7. Create the admin supplementary group without specifying a GID. [root@servera ~]# groupadd admin 8. Verify that both the operators and admin supplementary groups exist. 9. [root@servera ~]# tail /etc/group 10....output omitted... 11. operators:x:30000: admin:x:30001: 12. Ensure that the operator1, operator2, and operator3 users belong to the operators group.  1. Add the operator1, operator2, and operator3 users to the operators group. 2. [root@servera ~]# usermod -aG operators operator1 3. [root@servera ~]# usermod -aG operators operator2 [root@servera ~]# usermod -aG operators operator3 4. Confirm that the users are in the group. 5. [root@servera ~]# id operator1 6. uid=1002(operator1) gid=1002(operator1) groups=1002(operator1),30000( operators) 7. [root@servera ~]# id operator2 8. uid=1003(operator2) gid=1003(operator2) groups=1003(operator2),30000( operators) 9. [root@servera ~]# id operator3 uid=1004(operator3) gid=1004(operator3) groups=1004(operator3),30000( operators) 13. Ensure that the sysadmin1, sysadmin2, and sysadmin3 users belong to the admin group. Enable administrative rights for all the admin group members. Verify that any member of the admin group can run administrative commands. 1. Add the sysadmin1, sysadmin2, and sysadmin3 users to the admin group. 2. [root@servera ~]# usermod -aG admin sysadmin1 3. [root@servera ~]# usermod -aG admin sysadmin2 [root@servera ~]# usermod -aG admin sysadmin3 4. Confirm that the users are in the group. 5. [root@servera ~]# id sysadmin1 6. uid=1005(sysadmin1) gid=1005(sysadmin1) groups=1005(sysadmin1),30001( admin) 7. [root@servera ~]# id sysadmin2 8. uid=1006(sysadmin2) gid=1006(sysadmin2) groups=1006(sysadmin2),30001( admin) 9. [root@servera ~]# id sysadmin3 uid=1007(sysadmin3) gid=1007(sysadmin3) groups=1007(sysadmin3),30001( admin) 10. Examine the /etc/group file to verify the supplementary group memberships. 11. [root@servera ~]# tail /etc/group 12....output omitted... 13. operators:x:30000:operator1,operator2,operator3 admin:x:30001:sysadmin1,sysadmin2,sysadmin3 14. Create the /etc/sudoers.d/admin file so that the members of the admin group have full administrative privileges. [root@servera ~]# echo "%admin ALL=(ALL) ALL" >> /etc/sudoers.d/admin 15. Switch to the sysadmin1 user (a member of the admin group) and verify that you can run a sudo command. 16. [root@servera ~]# su - sysadmin1 17. [sysadmin1@servera ~]$ sudo cat /etc/sudoers.d/admin 18. [sudo] password for sysadmin1: redhat %admin ALL=(ALL) ALL 19. Return to the workstation machine as the student user. 20. [sysadmin1@servera ~]$ exit 21. logout 22. [root@servera ~]# exit 23. logout 24. [student@servera ~]$ exit 25. logout 26. Connection to servera closed.  [student@workstation ~]$ Manage User Passwords Objectives Set a password management policy for users, and manually lock and unlock user accounts. Shadow Passwords and Password Policy Originally, encrypted passwords were stored in the world-readable /etc/passwd file. These passwords were considered adequate until dictionary attacks on encrypted passwords became common. The cryptographically hashed passwords were moved to the /etc/shadow file, which only the root user can read. Like the /etc/passwd file, each user has an entry in the /etc/shadow file. An example entry from the /etc/shadow file has nine colon-separated fields: [root@host ~]# cat /etc/shadow...output omitted... user03:$6$CSsXsd3rwghsdfarf:17933:0:99999:7:2:18113: Each field of this code block is separated by a colon: user03 : Name of the user account. $6$CSsXsd3rwghsdfarf : The cryptographically hashed password of the user. 17933 : The days from the epoch when the password was last changed, where the epoch is 1970-01-01 in the UTC time zone. 0 : The minimum days since the last password change before the user can change it again. 99999 : The maximum days without a password change before the password expires. An empty field means that the password never expires. 7 : The number of days ahead to warn the user that their password will expire. 2 : The number of days without activity, starting with the day that the password expired, before the account is automatically locked. 18113 : The day when the account expires in days since the epoch. An empty field means that the account never expires. The last field is typically empty and is reserved for future use. Format of an Cryptographically Hashed Password The cryptographically hashed password field stores three pieces of information: the hashing algorithm in use, the salt, and the cryptographical hash. Salt adds random data to the cryptographical hash, for creating a unique hash to strengthen the cryptographically hashed password. Each piece of information is delimited by the dollar ($) character. $6$CSsXcYG1L/4ZfHr/$2W6evvJahUfzfHpc9X.45Jc6H30E 6 : The hashing algorithm in use for this password. A 6 indicates a SHA-512 hash, the RHEL 9 default; a 1 indicates MD5; and a 5 indicates SHA-256. CSsXcYG1L/4ZfHr/ : The salt in use to cryptographically hash the password; it is originally chosen at random. 2W6evvJahUfzfHpc9X.45Jc6H30E : The cryptographical hash of the user's password; combining the salt and the plain text password and then cryptographically hashing to generate the password hash. The primary reason to combine a salt with the password is to defend against attacks that use pre-computed lists of password hashes. Adding salts changes the resulting hashes, which makes the pre-computed list useless. If an attacker obtains a copy of an /etc/shadow file that uses salts, then they need to guess passwords with brute force, which requires more time and effort. Password Verification When a user tries to log in, the system looks up the entry for the user in the /etc/shadow file, and combines the salt for the user with the plain text typed password. The system then cryptographically hashes the combination of the salt and plain text password with the specified hashing algorithm. If the result matches the cryptographical hash, then the user typed the right password. If the result does not match the cryptographical hash, then the user typed the wrong password and the login attempt fails. This method enables the system to determine whether the user typed the correct password without storing that password in a usable form for logging in. Configure Password Aging The following diagram shows the relevant password aging parameters, which can be adjusted by using the chage command to implement a password aging policy. Notice that the command name is chage, which stands for "change age". Do not confuse the command with the word "change".  Figure 6.1: Password aging parameters The following example demonstrates the chage command to change the password policy of the sysadmin05 user. The command defines a minimum age (-m) of zero days, a maximum age (-M) of 90 days, a warning period (-W) of 7 days, and an inactivity period (-I) of 14 days. [root@host ~]# chage -m 0 -M 90 -W 7 -I 14 sysadmin05 Assume that you manage the user password policies on a Red Hat server. The cloudadmin10 user is new in the system, and you want to set a custom password aging policy. You want to set the account expiration 30 days from today, so you use the following commands: [root@host ~]# date +%F 2022-03-10 [root@host ~]# date -d "+30 days" +%F 2022-04-09 [root@host ~]# chage -E $(date -d "+30 days" +%F) cloudadmin10 [root@host ~]# chage -l cloudadmin10 | grep "Account expires" Account expires : Apr 09, 2022 Use the date command to get the current date. Use the date command to get the date 30 days from now. Use the chage command -E option to change the expiration date for the cloudadmin10 user. Use the chage command -l option to display the password aging policy for the cloudadmin10 user. After a few days, you notice in the /var/log/secure log file that the cloudadmin10 user has a strange behavior. The user tried to use sudo to interact with files that belong to other users. You suspect that the user might have left an ssh session open when working in another machine. You want the cloudadmin10 user to change the password on the next login, so you use the following command: [root@host ~]# chage -d 0 cloudadmin10 The next time that the cloudadmin10 user logs in, the user is prompted to change the password. NOTE The date command can calculate a future date. The -u option reports the time in UTC. [user01@host ~]$ date -d "+45 days" -u Thu May 23 17:01:20 UTC 2019 You can change the default password aging configuration in the /etc/login.defs file. The PASS_MAX_DAYS and PASS_MIN_DAYS options set the default maximum and minimum age of the password respectively. The PASS_WARN_AGE sets the default warning period of the password. Any change in the default password aging policies affects users that are created after the change. The existing users continue to use the earlier password aging settings rather than the later ones. For more information about the /etc/login.defs file, refer to the Red Hat Security: Linux in Physical, Virtual, and Cloud (RH415) course and the login.defs(5) man page. Restrict Access You can use the usermod command to modify account expiration for a user. For example, the usermod command -L option locks a user account and the user cannot log in to the system. [root@host ~]# usermod -L sysadmin03 [user01@host ~]$ su - sysadmin03 Password: redhat su: Authentication failure If a user leaves the company on a certain date, then you can lock and expire the account with a single usermod command. The date must be the number of days since 1970-01-01, or else use the YYYY-MM-DD format. In the following example, the usermod command locks and expires the cloudadmin10 user at 2022-08-14. [root@host ~]# usermod -L -e 2022-08-14 cloudadmin10 When you lock an account, you prevent the user from authenticating with a password to the system. This method is recommended to prevent access to an account by a former employee of the company. Use the usermod command - U option to enable the access to the account again. The nologin Shell The nologin shell acts as a replacement shell for the user accounts that are not intended to log in interactively to the system. It is good security practice to disable an account from logging in to the system when the account does not require it. For example, a mail server might require an account to store mail and a password for the user to authenticate with a mail client to retrieve mail. That user does not need to log in directly to the system. A common solution to this situation is to set the user's login shell to /sbin/nologin. If the user attempts to log in to the system directly, then the nologin shell closes the connection. [root@host ~]# usermod -s /sbin/nologin newapp [root@host ~]# su - newapp Last login: Wed Feb 6 17:03:06 IST 2019 on pts/0 This account is currently not available. IMPORTANT The nologin shell prevents interactive use of the system, but does not prevent all access. Users might be able to authenticate and upload or retrieve files through applications such as web applications, file transfer programs, or mail readers if they use the user's password for authentication. Guided Exercise: Manage User Passwords Set password policies for several users. Outcomes  Force a password change when the user logs in to the system for the first time. Force a password change every 90 days. Set the account to expire 180 days from the current day. As the student user on the workstation machine, use the lab command to prepare your system for this exercise. This command prepares your environment and ensures that all required resources are available. [student@workstation ~]$ lab start users-password Instructions 1. From workstation, open an SSH session as the student user to the servera machine. 2. [student@workstation ~]$ ssh student@servera [student@servera ~]$ 3. On servera, use the usermod command to lock and unlock the operator1 user. 1. As the student user, use administrative rights to lock the operator1 account. 2. [student@servera ~]$ sudo usermod -L operator1 [sudo] password for student: student 3. Try to log in as operator1. This command should fail. 4. [student@servera ~]$ su - operator1 5. Password: redhat su: Authentication failure 6. Unlock the operator1 account.  [student@servera ~]$ sudo usermod -U operator1 7. Try to log in as operator1 again. This time, the command should succeed. 8. [student@servera ~]$ su - operator1 9. Password: redhat 10....output omitted... [operator1@servera ~]$ 11. Log out of the operator1 user shell to return to the student user shell. 12. [operator1@servera ~]$ exit logout 4. Change the password policy for the operator1 user to require a new password every 90 days. Confirm that the password age is successfully set. 1. Switch to the root user. 2. [student@servera ~]$ sudo -i 3. [sudo] password for student: student [root@servera ~]# 4. Set the maximum age of the operator1 user's password to 90 days. [root@servera ~]# chage -M 90 operator1 5. Verify that the operator1 user's password expires 90 days after it is changed. 6. [root@servera ~]# chage -l operator1 7. Last password change : Mar 10, 2022 8. Password expires : Jun 10, 2022 9. Password inactive : never  10. Account expires : never 11. Minimum number of days between password change : 0 12. Maximum number of days between password change : 90 Number of days of warning before password expires : 7 5. Force a password change on the first login for the operator1 account. [root@servera ~]# chage -d 0 operator1 6. Exit as the root user from the servera machine. 7. [root@servera ~]# exit 8. logout [student@servera ~]$ 9. Log in as operator1 and change the password to forsooth123. After setting the password, return to the student user's shell. 1. Log in as operator1 and change the password to forsooth123 when prompted. 2. [student@servera ~]$ su - operator1 3. Password: redhat 4. You are required to change your password immediately (administrator e nforced) 5. Current password: redhat 6. New password: forsooth123 7. Retype new password: forsooth123 8....output omitted... [operator1@servera ~]$ 9. Exit the operator1 user's shell to return to the student user and then switch to the root user. 10. [operator1@servera ~]$ exit 11. logout  12. [student@servera ~]$ sudo -i 13. [sudo] password for student: student [root@servera ~]# 10. Set the operator1 account to expire 180 days from the current day. 1. Determine a date 180 days in the future. Use the format %F with the date command to get the exact value. This returned date is an example; use the value on your system for the steps after this one. 2. [root@servera ~]# date -d "+180 days" +%F 2022-09-06 3. Set the account to expire on the date that is displayed in the preceding step. For example: [root@servera ~]# chage -E 2022-09-06 operator1 4. Verify that the account expiry date is successfully set. 5. [root@servera ~]# chage -l operator1 6. Last password change : Mar 10, 2022 7. Password expires : Jun 10, 2022 8. Password inactive : never 9. Account expires : Sep 06, 2022 10. Minimum number of days between password change : 0 11. Maximum number of days between password change : 90 Number of days of warning before password expires : 7 11. Set the passwords to expire 180 days from the current date for all users. Use administrative rights to edit the configuration file. 1. Set PASS_MAX_DAYS to 180 in /etc/login.defs. Use administrative rights when you open the file with the text editor. You can use the vim /etc/login.defs command to perform this step. 2....output omitted... 3. # Password aging controls:  4. # 5. # PASS_MAX_DAYS Maximum number of days a password may be 6. # used. 7. # PASS_MIN_DAYS Minimum number of days allowed between 8. # password changes. 9. # PASS_MIN_LEN Minimum acceptable password length. 10. # PASS_WARN_AGE Number of days warning given before a 11. # password expires. 12. # 13. PASS_MAX_DAYS 180 14. PASS_MIN_DAYS 0 15. PASS_WARN_AGE 7...output omitted... IMPORTANT The default password and account expiry settings apply to new users but not to existing users. 16. Return to the workstation system as the student user. 17. [root@servera ~]# exit 18. logout 19. [student@servera ~]$ exit 20. logout 21. Connection to servera closed. [student@workstation ~]$ Lab: Manage Local Users and Groups Set a default local password policy, create a supplementary group for three users, allow that group to use sudo to run commands as root, and modify the password policy for one user. Outcomes  Set a default password aging policy of the local user's password. Create and use a supplementary group for new users. Create three new users with the new supplementary group. Set an initial password for the created users. Configure the supplementary group members to use the sudo command to run any command as any user. Set a user-specific password aging policy. As the student user on the workstation machine, use the lab command to prepare your system for this exercise. This command prepares your environment and ensures that all required resources are available. [student@workstation ~]$ lab start users-review Instructions 1. From the workstation machine, open an SSH session to the serverb machine as the student user and switch to the root user. 2. [student@workstation ~]$ ssh student@serverb 3....output omitted... 4. [student@serverb ~]$ sudo -i 5. [sudo] password for student: student [root@serverb ~]# Hide Solution 6. On the serverb machine, ensure that newly created users must change their passwords every 30 days. 1. Set PASS_MAX_DAYS to 30 in the /etc/login.defs file. Use administrative rights when opening the file with the text editor. You can use the vim /etc/login.defs command for this step. 2....output omitted... 3. # Password aging controls: 4. # 5. # PASS_MAX_DAYS Maximum number of days a password may be  6. # used. 7. # PASS_MIN_DAYS Minimum number of days allowed between 8. # password changes. 9. # PASS_MIN_LEN Minimum acceptable password length. 10. # PASS_WARN_AGE Number of days warning given before a 11. # password expires. 12. # 13. PASS_MAX_DAYS 30 14. PASS_MIN_DAYS 0 15. PASS_WARN_AGE 7...output omitted... 7. Hide Solution 8. Create the consultants group with a GID of 35000. [root@serverb ~]# groupadd -g 35000 consultants Hide Solution 9. Configure administrative rights to enable all consultants group members to execute any command as any user. Avoid using visudo to edit the /etc/sudoers file. Instead, place the configuration file in the /etc/sudoers.d directory. 1. Create the /etc/sudoers.d/consultants file and add the following content to it. You can use the vim /etc/sudoers.d/consultants command for this step. %consultants ALL=(ALL) ALL 10. Hide Solution 11. Create the consultant1, consultant2, and consultant3 users with the consultants group as their supplementary group. 12. [root@serverb ~]# useradd -G consultants consultant1 13. [root@serverb ~]# useradd -G consultants consultant2 [root@serverb ~]# useradd -G consultants consultant3  Hide Solution 14. Set the consultant1, consultant2, and consultant3 passwords to redhat. 15. [root@serverb ~]# passwd consultant1 16. Changing password for user consultant1. 17. New password: redhat 18. BAD PASSWORD: The password is shorter than 8 characters 19. Retype new password: redhat 20. passwd: all authentication tokens updated successfully. 21. [root@serverb ~]# passwd consultant2 22. Changing password for user consultant2. 23. New password: redhat 24. BAD PASSWORD: The password is shorter than 8 characters 25. Retype new password: redhat 26. passwd: all authentication tokens updated successfully 27. [root@serverb ~]# passwd consultant3 28. Changing password for user consultant3. 29. New password: redhat 30. BAD PASSWORD: The password is shorter than 8 characters 31. Retype new password: redhat passwd: all authentication tokens updated successfully Hide Solution 32. Set the consultant1, consultant2, and consultant3 accounts to expire in 90 days from the current day. 1. Determine the date 90 days in the future. This returned date is an example; the value that you see, to use in the following step, is based on the current date and time in your system. 2. [root@serverb ~]# date -d "+90 days" +%F 2022-06-08  3. Set the account expiry date of the consultant1, consultant2, and consultant3 accounts to the same value as determined in the preceding step. For example: 4. [root@serverb ~]# chage -E 2022-06-08 consultant1 5. [root@serverb ~]# chage -E 2022-06-08 consultant2 [root@serverb ~]# chage -E 2022-06-08 consultant3 33. Hide Solution 34. Change the password policy for the consultant2 account to require a new password every 15 days. [root@serverb ~]# chage -M 15 consultant2 Hide Solution 35. Additionally, force the consultant1, consultant2, and consultant3 users to change their passwords on the first login. 1. Set the last day of the password change to 0 so that users must change the password when they first log in to the system. 2. [root@serverb ~]# chage -d 0 consultant1 3. [root@serverb ~]# chage -d 0 consultant2 [root@serverb ~]# chage -d 0 consultant3 4. Return to the workstation system as the student user. 5. [root@serverb ~]# exit 6. logout 7. [student@serverb ~]$ exit 8. logout 9. Connection to serverb closed. [student@workstation ~]$ Summary The user account types in Linux are the superuser, system users, and regular users. A user has a primary group and might be a member of supplementary groups. The /etc/passwd, /etc/group, and /etc/shadow critical files contain user and group information. You can run commands as the superuser with the su and sudo commands. The useradd, usermod, and userdel commands manage users. The groupadd, groupmod, and groupdel commands manage groups. The passwd command manages passwords for users. The chage command displays and configures password expiration settings for users.