RED HAT ENTERPRISE LINUX

Managing Users, Groups,
and Superuser Access

Local Account Administration and Password Policies

CIS126RH | RHEL System Administration 1
Mesa Community College

Learning Objectives

Obtain superuser access

Use su and sudo to run commands with elevated privileges

Create and manage local users

Add, modify, and delete user accounts with useradd, usermod, userdel

Manage local groups

Create groups and manage memberships with groupadd, groupmod, gpasswd

Administer password policies

Configure password aging and account expiration with chage

We have four main learning objectives for this module. First, we'll learn how to obtain superuser access safely. This includes using su to switch users, sudo to run individual commands with elevated privileges, and understanding when to use each approach. Second, we'll master local user account management - creating new users with useradd, modifying existing accounts with usermod, and removing accounts with userdel. We'll understand the files involved and the options available. Third, we'll manage groups - creating them, adding and removing members, and understanding primary versus supplementary groups. Groups are fundamental to Linux access control. Fourth, we'll configure password policies using the chage command - setting password expiration, warning periods, and account lockout. These policies are essential for security compliance. Let's begin with superuser access.

The Root User

root (UID 0) is the superuser account with unrestricted access to the entire system. Root can read any file, modify any setting, and execute any command.

Root Can:

Read/write any file on the system
Install and remove software
Manage all users and groups
Configure network and services
Mount filesystems
Change ownership and permissions

Dangers of Root:

Typos can be catastrophic
No confirmation for destructive actions
Malware runs with full privileges
Hard to audit who did what
Accidents affect entire system
No "undo" for many operations

Best Practice: Never log in directly as root. Use sudo for individual commands instead.

The root user, also known as the superuser, has User ID 0 and unlimited privileges on a Linux system. Root can access any file regardless of permissions, modify system configurations, install software, and control all services. This power is necessary for system administration, but it's also dangerous. The dangers of running as root are significant. A simple typo like "rm -rf / tmp" (with an accidental space) can destroy the entire filesystem. There's no confirmation, no undo, no recovery. If malware compromises a root session, it has complete control of the system. When multiple administrators share the root account, there's no way to audit who made which changes. For these reasons, the modern best practice is to never log in directly as root for normal work. Instead, use your regular user account and elevate privileges only when needed, using sudo for individual commands. This provides accountability (logs show who ran what), reduces the window of vulnerability, and limits the blast radius of mistakes. RHEL 8 and later even allow installation with root login disabled entirely, forcing sudo usage.

Switching Users: su

# Switch to root (prompts for root password)
[student@server ~]$ su
Password: [enter root password]
[root@server student]#

# Switch to root with login environment (recommended)
[student@server ~]$ su -
Password:
[root@server ~]#

# Switch to another user
[student@server ~]$ su - jsmith
Password: [enter jsmith's password]
[jsmith@server ~]$

# Run single command as another user
[student@server ~]$ su -c "whoami" jsmith
Password:
jsmith

# Exit back to original user
[root@server ~]# exit
[student@server ~]$

su vs su -: The dash (-) creates a login shell with the target user's environment. Without it, you keep your current environment variables.

The su command (substitute user or switch user) lets you become another user. Without arguments, su switches to root. You'll need to enter the root password. Notice the prompt changes from $ to # indicating root privileges. The critical distinction is between "su" and "su -" (with a dash). Plain "su" gives you root privileges but keeps your current environment - your PATH, working directory, and other variables. "su -" creates a login shell that initializes the full root environment, including root's PATH, home directory, and profile scripts. Always use "su -" when becoming root to ensure you have the proper environment for administrative commands. You can switch to any user by specifying their username. "su - jsmith" makes you jsmith, using their password. The -c option runs a single command as the target user and returns to your original shell - useful for one-off tasks. Type "exit" to return to your original user identity. The su command's main limitation is that it requires knowing the target user's password. For root access, this means sharing the root password among administrators, which is problematic for security and auditing.

Elevated Privileges: sudo

sudo (superuser do) runs a single command with elevated privileges. Users authenticate with their own password and must be authorized in the sudoers configuration.

# Run command as root
[student@server ~]$ sudo systemctl restart httpd
[sudo] password for student: [enter YOUR password]

# View who you become with sudo
[student@server ~]$ sudo whoami
root

# Run command as specific user
[student@server ~]$ sudo -u apache cat /etc/httpd/conf/httpd.conf

# Open root shell (use sparingly)
[student@server ~]$ sudo -i
[root@server ~]#

# List your sudo privileges
[student@server ~]$ sudo -l

sudo is the modern, preferred method for obtaining elevated privileges. Unlike su, sudo lets users run privileged commands using their own password, not the root password. This is a significant security improvement - you don't need to share the root password with anyone. When you run a sudo command, you enter your own password. The system checks the sudoers configuration to verify you're authorized for that command. If allowed, the command runs with root privileges. Subsequent sudo commands within a timeout period (usually 5 minutes) don't require re-entering your password. The -u option specifies a different user to run the command as - useful for testing permissions or running commands as service accounts. "sudo -i" opens an interactive root shell, similar to "su -". Use this sparingly - it's convenient but loses the per-command auditing benefit of sudo. "sudo -l" shows what commands you're allowed to run, helpful when you're unsure of your privileges. Every sudo command is logged, typically to /var/log/secure, providing an audit trail of who ran what commands. This accountability is a major advantage over sharing the root password.

sudo Configuration

# Edit sudoers safely (ALWAYS use visudo!)
[root@server ~]# visudo

# sudoers file syntax examples:

# User privilege specification
student    ALL=(ALL)    ALL           # Full sudo access

# Allow without password
operator   ALL=(ALL)    NOPASSWD: ALL

# Limit to specific commands
backup     ALL=(ALL)    /usr/bin/rsync, /usr/bin/tar

# Group-based access (note the %)
%wheel     ALL=(ALL)    ALL           # Members of wheel group
%admins    ALL=(ALL)    NOPASSWD: /usr/bin/systemctl

# Drop-in files (recommended method)
[root@server ~]# cat /etc/sudoers.d/student
student    ALL=(ALL)    ALL

⚠ Always use visudo! It validates syntax before saving. A broken sudoers file can lock you out of sudo entirely.

sudo's behavior is controlled by the /etc/sudoers file and files in /etc/sudoers.d/. Always edit sudoers using the visudo command, never with a regular text editor. visudo checks syntax before saving - a single syntax error in sudoers can completely break sudo, potentially locking you out of administrative access. The sudoers syntax follows the pattern: who where=(as_whom) what. "student ALL=(ALL) ALL" means: user student, on all hosts, may run as all users, any command. The NOPASSWD tag allows commands without entering a password - useful for scripts and automation, but reduces security. You can limit sudo to specific commands. The backup user example only allows rsync and tar - suitable for a backup operator who shouldn't have full root access. Groups are specified with a percent sign. "%wheel ALL=(ALL) ALL" grants sudo access to all wheel group members. This is the default RHEL configuration - add users to the wheel group to grant them sudo privileges. Rather than editing /etc/sudoers directly, best practice is to create files in /etc/sudoers.d/. These are included automatically and are easier to manage, especially with configuration management tools. Files here must not contain dots in the name.

The wheel Group

On RHEL, the wheel group grants sudo access to its members. This is the standard way to allow users administrative privileges.

# Add user to wheel group for sudo access
[root@server ~]# usermod -aG wheel student

# Verify membership
[student@server ~]$ groups
student wheel

# Check the sudoers configuration
[root@server ~]# grep wheel /etc/sudoers
%wheel  ALL=(ALL)       ALL

# Group must be effective - logout/login or use newgrp
[student@server ~]$ newgrp wheel

# Now sudo should work
[student@server ~]$ sudo whoami
root

RHCSA Tip: Adding a user to the wheel group is the standard way to grant administrative access on RHEL systems.

The wheel group is RHEL's standard mechanism for granting sudo access. Rather than editing sudoers for each user, you simply add users to the wheel group, and the default sudoers configuration grants them full sudo privileges. The usermod -aG command adds a user to a supplementary group. The -a flag is critical - it means "append" to existing groups. Without -a, the user would be removed from all other groups! Always use -aG together when adding to groups. After adding someone to wheel, they may need to log out and back in for the new group membership to take effect. Alternatively, the newgrp command starts a new shell with the specified group active. You can verify sudoers is configured for wheel with grep. The %wheel line grants all wheel group members full sudo access. This pattern - group-based sudo access - is cleaner than individual user entries. It's easy to audit (list wheel members to see who has admin access), and revoking access just means removing someone from the group. For the RHCSA exam, remember: to grant a user administrative privileges, add them to the wheel group with "usermod -aG wheel username".

User Account Files

File	Purpose	Permissions
/etc/passwd	User account information	644 (world-readable)
/etc/shadow	Encrypted passwords, aging	000 (root only)
/etc/group	Group definitions	644 (world-readable)
/etc/gshadow	Group passwords (rarely used)	000 (root only)
/etc/login.defs	Default settings for useradd	644
/etc/default/useradd	Additional useradd defaults	644

Never edit these files directly! Use the provided commands (useradd, usermod, passwd, etc.) to ensure consistency and proper locking.

User and group information is stored in several text files. Understanding these helps you troubleshoot and understand what the management commands actually do. /etc/passwd contains one line per user with account information. Despite the name, it no longer contains passwords - those moved to /etc/shadow for security. It's world-readable so programs can look up username-to-UID mappings. /etc/shadow contains encrypted passwords and password aging information. It's readable only by root (actually permission 000 with special handling) to protect password hashes from offline cracking attempts. /etc/group lists all groups and their members. Like passwd, it's world-readable for group name lookups. /etc/gshadow is the shadow file for groups, containing group passwords. Group passwords are rarely used in practice. /etc/login.defs contains system-wide defaults for user creation - UID ranges, password aging defaults, home directory location. /etc/default/useradd has additional defaults like default shell and skeleton directory. While you can examine these files to understand the system, always use the proper commands to modify them. The commands handle file locking, maintain consistency between files, and update related systems like SELinux contexts.

Understanding /etc/passwd

student:x:1000:1000:Student User:/home/student:/bin/bash

Field	Name	Description
1	Username	Login name (max 32 characters)
2	Password	x = password in /etc/shadow
3	UID	User ID number
4	GID	Primary group ID
5	GECOS	Comment/full name
6	Home	Home directory path
7	Shell	Login shell

# View specific user's entry
grep student /etc/passwd
student:x:1000:1000:Student User:/home/student:/bin/bash

The /etc/passwd file contains seven colon-separated fields for each user. Understanding this format helps you interpret user information and troubleshoot account issues. Field 1 is the username - the name used to log in. It's limited to 32 characters and traditionally lowercase. Field 2 historically contained the password but now just holds 'x' indicating the password is stored in /etc/shadow. Field 3 is the User ID (UID), a numeric identifier. The kernel actually works with UIDs, not usernames. UID 0 is root. Field 4 is the primary Group ID (GID). Every user has one primary group, typically matching their UID for user private groups. Field 5 is the GECOS field (named for historical reasons), containing the user's full name or description. Some systems store additional info like phone numbers here. Field 6 is the home directory path - where the user lands after login and where their personal files are stored. Field 7 is the login shell - the command interpreter started at login. /bin/bash is standard for interactive users. /sbin/nologin prevents interactive login for system accounts. You can quickly look up any user's information by grepping this file, though the getent command is preferred for systems using network authentication.

UID Ranges

System Accounts

0 - 999

root (0), bin, daemon,
apache, nobody, etc.

Regular Users

1000 - 60000

Normal user accounts
First user typically gets 1000

# Check UID range configuration
grep -E "^UID_MIN|^UID_MAX|^SYS_UID" /etc/login.defs
UID_MIN                  1000
UID_MAX                 60000
SYS_UID_MIN               201
SYS_UID_MAX               999

# Create system user (UID below 1000)
useradd -r -s /sbin/nologin myservice

# View result
id myservice
uid=987(myservice) gid=984(myservice) groups=984(myservice)

Linux divides UIDs into ranges for different purposes. Understanding these ranges helps you identify account types and create appropriate accounts. UIDs 0-999 are reserved for system accounts. UID 0 is always root. Other system accounts like bin, daemon, apache, and nobody have UIDs in this range. These accounts typically can't log in interactively and are used to run services with limited privileges. UIDs 1000-60000 (by default) are for regular user accounts. When you create a normal user, they get the next available UID in this range. The first user on a fresh system typically gets UID 1000. These ranges are configured in /etc/login.defs. You can view and modify the boundaries there. Different organizations may use different ranges, especially in environments with centralized authentication. The useradd -r option creates a system user with a UID below 1000. System users are typically created for running services - they don't need home directories or login shells, and keeping them in a separate UID range makes it easy to distinguish them from real users. The id command shows a user's UID, primary GID, and all group memberships - very useful for verifying account configuration.

Creating Users: useradd

# Create user with defaults
[root@server ~]# useradd jsmith

# Create user with options
[root@server ~]# useradd -c "John Smith" -s /bin/bash -m -d /home/jsmith jsmith

# Common options:
useradd -u 1500 username      # Specify UID
useradd -g developers username # Specify primary group
useradd -G wheel,dev username  # Add to supplementary groups
useradd -s /sbin/nologin svc   # No interactive login
useradd -e 2025-12-31 temp     # Account expiration date
useradd -r serviceacct         # Create system user

# View what useradd would do without creating
useradd -D
GROUP=100
HOME=/home
INACTIVE=-1
EXPIRE=
SHELL=/bin/bash
SKEL=/etc/skel

The useradd command creates new user accounts. With just a username, it uses defaults from /etc/login.defs and /etc/default/useradd. The -c option sets the comment field (GECOS), typically the user's full name. Use quotes if it contains spaces. The -s option specifies the login shell. /bin/bash is standard for interactive users. /sbin/nologin prevents login - used for service accounts. The -m flag explicitly creates the home directory (this is default behavior on RHEL but good to be explicit). The -d option specifies a non-standard home directory location. The -u option sets a specific UID instead of using the next available. Useful when migrating users or maintaining consistency across systems. The -g option sets the primary group. Without it, useradd creates a private group matching the username. The -G option (capital G) adds the user to supplementary groups at creation time - note this is a comma-separated list with no spaces. The -e option sets an account expiration date in YYYY-MM-DD format. After this date, the account cannot log in. The -r option creates a system account with UID below 1000, no home directory, and no aging information. "useradd -D" shows the default values that would be applied. You can also use it to change defaults.

Setting Passwords

# Set/change password interactively
[root@server ~]# passwd jsmith
Changing password for user jsmith.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

# User changes their own password
[jsmith@server ~]$ passwd
Changing password for user jsmith.
Current password: 
New password:

# Set password non-interactively (scripts)
[root@server ~]# echo "newpassword" | passwd --stdin jsmith

# Force password change at next login
[root@server ~]# passwd -e jsmith
Expiring password for user jsmith.

# Lock an account
[root@server ~]# passwd -l jsmith   # Lock
[root@server ~]# passwd -u jsmith   # Unlock

⚠ Security Note: The --stdin method puts passwords in shell history and process listings. Use carefully!

After creating a user with useradd, the account has no password and cannot log in until one is set. The passwd command manages passwords. Root can change anyone's password by specifying the username - and isn't prompted for the current password. Regular users run passwd without arguments to change their own password - they must enter their current password first. For scripting and automation, --stdin reads the password from standard input. The example uses echo and a pipe. While convenient, this has security implications - the password may appear in shell history, process listings, and anywhere the script is stored. For production automation, consider Ansible vault or similar secure methods. The -e option expires the password immediately, forcing the user to change it at next login. This is useful when creating accounts - you set a temporary password, then expire it so the user must choose their own. The -l option locks an account by prefixing the password hash with an exclamation mark, preventing any password from matching. The account still exists, but password authentication fails. The -u option unlocks by removing the prefix. Locking is useful for temporarily disabling accounts without deleting them.

Modifying Users: usermod

# Change user's comment (full name)
[root@server ~]# usermod -c "John A. Smith" jsmith

# Change login shell
[root@server ~]# usermod -s /bin/zsh jsmith

# Add user to supplementary groups (KEEP -a!)
[root@server ~]# usermod -aG wheel jsmith
[root@server ~]# usermod -aG wheel,developers jsmith

# Change primary group
[root@server ~]# usermod -g developers jsmith

# Lock/unlock account
[root@server ~]# usermod -L jsmith    # Lock
[root@server ~]# usermod -U jsmith    # Unlock

# Change username
[root@server ~]# usermod -l johnsmith jsmith

# Move home directory
[root@server ~]# usermod -d /home/johnsmith -m johnsmith

CRITICAL: Always use -aG together when adding groups! Using -G alone removes all other supplementary groups!

The usermod command modifies existing user accounts. Its options mirror useradd but change existing settings rather than setting initial values. The -c option updates the comment field. The -s option changes the login shell. The -aG combination is one of the most important and commonly mistaken commands. The -G option sets supplementary groups, but if used alone, it REPLACES all existing supplementary groups with only the ones specified. The -a flag means APPEND, adding to existing groups. Always use -aG together when adding users to groups - forgetting -a can accidentally remove users from all their other groups, including wheel. The -g option (lowercase) changes the primary group - different from supplementary groups. The -L and -U options lock and unlock accounts, similar to passwd -l and -u. The -l option renames the user account. Note this doesn't change the home directory name. The -d option changes the home directory. The -m flag moves the contents from the old location to the new one. Without -m, you just change where the system thinks the home is without moving files. For the RHCSA exam, the -aG pattern for adding users to groups is especially important to remember.

Deleting Users: userdel

# Delete user (keeps home directory)
[root@server ~]# userdel jsmith

# Delete user AND home directory
[root@server ~]# userdel -r jsmith

# Force delete even if user is logged in
[root@server ~]# userdel -f jsmith

# Check for files owned by deleted user's UID
[root@server ~]# find / -nouser 2>/dev/null

# Before deleting, check what they own
[root@server ~]# find / -user jsmith 2>/dev/null

Without -r:

Home directory remains
Mail spool remains
Files become orphaned (owned by UID)

With -r:

Removes home directory
Removes mail spool
Other files still orphaned

The userdel command removes user accounts. By default, it removes only the account entry from /etc/passwd and /etc/shadow - the user's files remain on the system. This is a safety feature - you might want to preserve files for handoff to another employee or audit purposes. The -r option removes the home directory and mail spool in addition to the account. Use this when you truly want to clean up completely. The -f option forces removal even if the user is currently logged in or has running processes. Be careful with this - killing their processes abruptly could cause data loss or corruption. An important consideration: when you delete a user, files they owned outside their home directory become "orphaned" - owned by a numeric UID that no longer maps to a username. If you later create a new user who happens to get the same UID, they'll own those files. Use "find / -user username" before deletion to see what files exist outside the home directory. After deletion, "find / -nouser" finds orphaned files owned by UIDs that don't correspond to any user. You should either delete these, change their ownership, or ensure they're in backed-up locations.

Managing Groups

# Create a new group
[root@server ~]# groupadd developers

# Create group with specific GID
[root@server ~]# groupadd -g 5000 webteam

# Create system group
[root@server ~]# groupadd -r appgroup

# Modify group - change name
[root@server ~]# groupmod -n devteam developers

# Modify group - change GID
[root@server ~]# groupmod -g 6000 devteam

# Delete a group
[root@server ~]# groupdel devteam

# View group information
[root@server ~]# getent group developers
developers:x:5001:jsmith,ajones

# View a user's groups
[student@server ~]$ groups
student wheel developers

Groups allow you to manage permissions for multiple users collectively. The groupadd command creates new groups. Without options, it assigns the next available GID. The -g option specifies a particular GID. The -r option creates a system group with a GID below 1000. The groupmod command modifies existing groups. The -n option changes the group name. The -g option changes the GID - be careful with this as it can orphan files that were owned by the old GID. The groupdel command removes a group. You cannot delete a group that is any user's primary group - you'd need to change those users' primary groups first. The group's files remain but become owned by an orphaned GID. The getent command is useful for looking up group information, especially on systems using network authentication where the group might not be in /etc/group. The output shows group name, password placeholder, GID, and comma-separated list of members. The groups command shows what groups the current user (or specified user) belongs to. The id command also shows this information along with UIDs. Understanding the distinction between primary and supplementary groups is important - a user has exactly one primary group (for new file creation) and zero or more supplementary groups (for access control).

Group Membership

# Add user to group (preferred method)
[root@server ~]# usermod -aG developers jsmith

# Add user to group using gpasswd
[root@server ~]# gpasswd -a jsmith developers
Adding user jsmith to group developers

# Remove user from group
[root@server ~]# gpasswd -d jsmith developers
Removing user jsmith from group developers

# Set group administrators
[root@server ~]# gpasswd -A jsmith developers

# List group members
[root@server ~]# getent group developers
developers:x:5001:jsmith,ajones,bwilson

# Alternative: use lid to show user's groups
[root@server ~]# lid -g developers
 jsmith(uid=1000)
 ajones(uid=1001)

Primary vs Supplementary: Users have ONE primary group (for new files) and can have MULTIPLE supplementary groups (for access).

There are multiple ways to manage group membership. The usermod -aG method we covered is the most common. The gpasswd command provides another approach with some advantages. "gpasswd -a user group" adds a user to a group - straightforward and hard to make the mistake of forgetting -a. "gpasswd -d user group" removes a user from a group. This is cleaner than trying to use usermod -G to remove someone. "gpasswd -A user group" designates a user as a group administrator who can add and remove members without root privileges. This delegates group management. The getent group command shows group members. Note that it only shows users for whom this is a supplementary group - users whose primary group is this group won't be listed here (they're identified by the GID in /etc/passwd instead). The lid command (from libuser) provides another view, showing which users are members of a group or which groups a user belongs to. The key concept is understanding primary versus supplementary groups. The primary group is set in /etc/passwd and determines the group ownership of files the user creates. Supplementary groups, listed in /etc/group, provide additional access rights. A user can be in many supplementary groups but has exactly one primary group.

Understanding /etc/shadow

jsmith:$6$xyz...:19500:0:99999:7:::

Field	Name	Description
1	Username	Login name
2	Password Hash	Encrypted password (!! = no password, ! = locked)
3	Last Change	Days since Jan 1, 1970 of last password change
4	Minimum Age	Days before password CAN be changed
5	Maximum Age	Days before password MUST be changed
6	Warning Period	Days of warning before expiration
7	Inactive Period	Days after expiration before account locks
8	Expiration Date	Days since epoch when account expires

The /etc/shadow file stores password information securely. Only root can read it. Understanding its fields is essential for password policy management. Field 1 is the username, matching /etc/passwd. Field 2 contains the encrypted password hash. The prefix indicates the algorithm: $6$ is SHA-512, $5$ is SHA-256. Double exclamation marks (!!) mean no password has been set. A single exclamation mark prefix means the account is locked. Field 3 is the last password change date, expressed as days since January 1, 1970 (the Unix epoch). Field 4 is the minimum age - users must wait this many days before they can change their password again. This prevents users from immediately changing back to an old password. Field 5 is the maximum age - users must change their password within this many days. After this, the password expires. Field 6 is the warning period - users see warnings this many days before expiration. Field 7 is the inactive period - the grace period after expiration during which the user can still log in but must change their password. After this, the account locks. Field 8 is the account expiration date (not password expiration) - after this date, the account cannot be used at all regardless of password status.

Password Aging: chage

# View current aging settings
[root@server ~]# chage -l jsmith
Last password change                    : Dec 01, 2025
Password expires                        : Mar 01, 2026
Password inactive                       : never
Account expires                         : never
Minimum number of days between password change    : 0
Maximum number of days between password change    : 90
Number of days of warning before password expires : 7

# Set maximum password age (90 days)
[root@server ~]# chage -M 90 jsmith

# Set minimum age (1 day - prevents immediate changes)
[root@server ~]# chage -m 1 jsmith

# Set warning days (14 days before expiration)
[root@server ~]# chage -W 14 jsmith

# Set inactive period (30 days after expiration)
[root@server ~]# chage -I 30 jsmith

# Force password change at next login
[root@server ~]# chage -d 0 jsmith

The chage command (change age) manages password aging policies. It's essential for security compliance. The -l option displays current settings in human-readable format. This is your go-to command for checking a user's password status. The -M option sets maximum password age in days. After this many days, the password expires and must be changed. Common values are 60, 90, or 180 days depending on security requirements. The -m option sets minimum age - users must wait this many days before changing their password again. This prevents someone from changing their password multiple times to cycle back to an old password when history is enforced. Setting it to 1 is common. The -W option sets the warning period. Users see "Your password will expire in N days" warnings starting this many days before expiration. The -I option sets the inactive period - the grace period after password expiration. During this time, users can still log in but are immediately forced to change their password. After the inactive period, the account is locked and requires administrator intervention. The -d 0 trick sets the last change date to day 0 (before the epoch), which makes the password appear expired, forcing a change at next login. This is commonly used when creating accounts with temporary passwords.

Account Expiration

# Set account expiration date
[root@server ~]# chage -E 2025-12-31 contractor

# Alternative: use usermod
[root@server ~]# usermod -e 2025-12-31 contractor

# Remove account expiration (never expires)
[root@server ~]# chage -E -1 contractor

# Interactive mode - prompts for all values
[root@server ~]# chage contractor
Changing the aging information for contractor
Enter the new value, or press ENTER for the default

    Minimum Password Age [0]: 1
    Maximum Password Age [99999]: 90
    ...

# Verify account status
[root@server ~]# chage -l contractor | grep "Account expires"
Account expires                         : Dec 31, 2025

Use Case: Account expiration is perfect for contractors, interns, and temporary employees - set it when creating the account and it auto-disables.

Account expiration is different from password expiration. Password expiration forces a password change; account expiration completely disables the account. The -E option sets the date when the account becomes inactive. After this date, the user cannot log in at all - the system won't even prompt for a password. The date format is YYYY-MM-DD. usermod -e accomplishes the same thing. Use whichever command you remember or is more convenient in context. To remove an expiration date, set it to -1, which means "never expires" or clear the field. Running chage with just a username enters interactive mode, prompting for each aging value. This is useful when you need to set multiple values and want to see the current settings as you go. Account expiration is extremely valuable for temporary workers. When you create an account for a contractor whose project ends December 31st, set the expiration at creation time. You don't need to remember to disable the account later - it happens automatically. This reduces security risk from forgotten accounts. The distinction to remember: password expiration (-M) forces password changes but allows login. Account expiration (-E) completely prevents login after the date, regardless of password status.

Default Policies

# View/edit system-wide defaults
[root@server ~]# cat /etc/login.defs | grep PASS
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    5
PASS_WARN_AGE   7

# Edit to set organization policy
[root@server ~]# vim /etc/login.defs
# Change to:
PASS_MAX_DAYS   90
PASS_MIN_DAYS   1
PASS_MIN_LEN    12
PASS_WARN_AGE   14

# These defaults apply to NEW users only!
# Existing users keep their current settings

# Apply policy to existing user
[root@server ~]# chage -M 90 -m 1 -W 14 existinguser

⚠ Important: Changes to /etc/login.defs only affect newly created users. Use chage to update existing accounts.

The /etc/login.defs file contains system-wide defaults for password aging. Understanding what you can set here versus what requires per-user commands is important. PASS_MAX_DAYS is the default maximum password age for new accounts. The default 99999 effectively means no expiration. Organizations typically change this to 90 or similar. PASS_MIN_DAYS is the default minimum age. Zero means users can change passwords any time. Setting to 1 or more prevents password cycling. PASS_MIN_LEN sets minimum password length. Note that PAM modules (pam_pwquality) often enforce more sophisticated requirements. PASS_WARN_AGE sets the default warning period. A crucial point: changing login.defs only affects users created AFTER the change. Existing users retain their current settings. To update existing users, you must use chage for each one. In enterprise environments, configuration management tools like Ansible can apply these settings consistently across all users and systems. For the RHCSA exam, know how to both set defaults for new users (login.defs) and modify existing users (chage). You might be asked to ensure all users, existing and new, meet a particular policy.

Key Takeaways

Superuser access: Use sudo for individual commands, avoid logging in as root. Add users to wheel group.

User management: useradd, usermod, userdel, passwd - set passwords after creating users!

Groups: groupadd, usermod -aG (always use -aG together!), gpasswd

Password policy: chage -M (max age), -m (min), -W (warn), -E (account expiration)

Let's summarize the key points from this comprehensive module. For superuser access, the modern approach is using sudo for individual commands rather than logging in as root. This provides accountability through logging and limits exposure. The wheel group is the standard way to grant sudo access on RHEL - usermod -aG wheel username is the key command. For user management, useradd creates accounts, usermod modifies them, userdel removes them, and passwd sets passwords. Remember that useradd creates accounts without passwords - you must set one before the user can log in, or expire it to force them to set their own. For groups, groupadd creates them, and usermod -aG adds members. The -aG combination is critical - without -a, you'll remove all existing group memberships. gpasswd provides an alternative for adding and removing members. For password policies, chage is your primary tool. -M sets maximum age, -m sets minimum age, -W sets warning period, -E sets account expiration. The -l option displays current settings, and -d 0 forces password change.

Graded Lab

Create user "devuser" with home directory and bash shell, add to wheel group
Set devuser's password, then expire it so they must change at next login
Create group "developers" and add devuser as a member
Set password policy: max 90 days, min 1 day, warn 14 days
Create contractor account that expires on a specific date

Next: Controlling Access to Files