RHEL Users, Groups, sudo and Authentication

Anil Jalela · Published Sep 3, 2026 · 8 min read

An account is an operational identity with an owner, purpose, authentication path, authorization and lifecycle. Creating a username is easy; proving who controls it, what it can do, where its actions are recorded and how access is removed is the real work. Shared root passwords and broad sudo rules make incidents faster to cause and harder to attribute.

Separate identity, authentication and authorization

Identity answers which principal is acting. Authentication establishes evidence for that claim. Authorization decides which operation the principal may perform. Local files, SSSD-backed enterprise identity, SSH keys, certificates, PAM and sudo can participate in different layers. A successful SSH login does not imply sudo access, and a sudo rule does not define how the user authenticated.

Human accounts should be individual and attributable. Service accounts need an owner, application purpose, restricted login behavior, protected credentials and retirement date. UID and GID consistency matter for shared filesystems and restored data. Never renumber an active identity without inventorying every file, ACL, process and external mapping that depends on it.

Build the working model

Implementation sequence

1. Classify the identity. Record whether it is human, service, break-glass or external, plus owner and expiry.
2. Choose the authoritative source. Avoid creating a local shadow identity when enterprise authentication owns the namespace.
3. Allocate groups by function. Grant access to a role group instead of changing every file or issuing shared credentials.
4. Write the narrow sudo rule. Match exact commands and arguments where practical; avoid shell escapes and writable command paths.
5. Validate before activation. Use visudo -cf, keep a root console and test both permitted and denied operations in a second session.
6. Review and retire. Disable access first when appropriate, inventory owned state and scheduled work, then remove under an approved retention decision.

Commands and expected evidence

getent passwd laboperator
getent group webops
id laboperator
useradd --create-home --shell /bin/bash laboperator
groupadd webops
usermod --append --groups webops laboperator
passwd --status laboperator
chage --list laboperator
sudo -l -U laboperator
visudo -cf /etc/sudoers
sssctl user-checks laboperator 2>/dev/null || true
lastlog -u laboperator
journalctl _COMM=sudo --since today --no-pager

• getent queries configured identity sources, while reading /etc/passwd alone shows only local records.
• usermod --append --groups preserves existing supplementary groups. Omitting --append can remove unrelated access.
• visudo -cf validates syntax but cannot prove the rule grants only the intended semantic capability. Review the called command and writable inputs.
• sudo -l -U helps inspect policy. Test in the real session context because host, group, authentication and included policy can change the result.

Evidence and acceptance criteria

Worked scenario: a narrow sudo command still grants a shell

An operations group is permitted to run a text editor as root so members can change one configuration file. The command looks narrow, but the editor can open other files and launch a shell. The rule therefore grants general root capability while the access record describes it as application-only.

The team replaces the editor rule with a controlled deployment command that accepts one reviewed file from a protected staging directory, validates its ownership and syntax, installs it with fixed mode, records the digest and reloads the exact service. The operator can perform the required task without an unrestricted editor or shell.

Practical how-to cases

sudo useradd -m -s /bin/bash operator1
sudo passwd operator1
sudo usermod -aG wheel operator1
id operator1
sudo -l -U operator1
getent passwd operator1

printf '%%webops ALL=(root) /usr/bin/systemctl status httpd.service, /usr/bin/systemctl restart httpd.service\n' | sudo tee /etc/sudoers.d/webops-httpd
sudo chmod 440 /etc/sudoers.d/webops-httpd
sudo visudo -cf /etc/sudoers.d/webops-httpd
sudo -l -U operator1

sudo chage -M 90 -m 1 -W 14 operator1
sudo chage -l operator1
sudo passwd -S operator1
sudo faillock --user operator1

sudo usermod -L -s /sbin/nologin operator1
sudo pkill -u operator1 2>/dev/null || true
sudo find / -xdev -user operator1 -ls 2>/dev/null
sudo crontab -u operator1 -l 2>/dev/null || true
lastlog -u operator1

Independent practice tasks

1. Create a service account with no interactive shell and a controlled data directory.
2. Configure a sudo rule for one maintenance script, then prove unrelated commands are denied.
3. Set and verify account expiry, password expiry and a temporary lock as three separate controls.
4. Retire a lab user while preserving a manifest of owned files and scheduled jobs.

For this lesson on RHEL Identity and sudo Administration, complete each task without copying the worked command sequence. Record the initial state, exact change, verification, negative test and recovery command. A task is unfinished if it works now but does not survive a reboot where persistence is required.

Troubleshooting by symptom

Unsafe operations and recovery boundaries

• Unsafe: ALL=(ALL) NOPASSWD: ALL gives broad unattributed privilege and removes an authentication control. Use the smallest reviewed command set and central session controls.
• Unsafe: deleting an account before inventorying processes, files, scheduled jobs and encryption ownership can orphan services or data.
• Unsafe: editing PAM, SSSD, sudo or SSH remotely without console access and a retained privileged session can lock out every administrator.

Rewritten knowledge checks

Guided lab and acceptance test

1. Create two lab users and one functional group, then record numeric and resolved identity evidence.
2. Give the group access to a lab directory using setgid and a default ACL; verify intended and denied access.
3. Create a sudoers drop-in allowing one harmless root-owned wrapper with fixed arguments. Validate it with visudo -cf.
4. Test the allowed command, a changed argument and an unrelated command from a new session.
5. Lock one lab account and prove how login and existing sessions behave without deleting its files.
6. Remove the lab identities only after inventorying their files, processes and scheduled work.

Primary references

• RHEL 10 configuring authentication and authorization
• RHEL 10 documentation
• RHEL 9 documentation