KNZLABS :: RHCSA Foundations

Module 7: Manage Users and Groups

RHCSA domain covered: Manage Users and Groups (8).

Lab in this kit: Lab 01.

User and group management is bread-and-butter sysadmin work, and the exam tests it heavily because it touches everything else — file ownership, sudo access, SSH logins, service accounts. The mental model is simple once you see it: a handful of plain-text database files define who exists and what they can do, and a small set of commands edit those files safely. The recurring traps are all about *not clobbering existing state* (the -a on group changes) and *persistence* (aging and locks that actually stick).

The account database files

What it is: four plain-text files under /etc hold all local account data.

Why it matters: understanding which file holds what — and which is readable by whom — explains the behavior of every user command and is itself testable.

FileWhat's in itMode
/etc/passwdUsername, UID, GID, GECOS, home, shell0644 (world-readable)
/etc/shadowUsername, hashed password, aging info0000 (root-only)
/etc/groupGroup name, GID, member list0644
/etc/gshadowGroup passwords (rarely used)0000

The split between passwd and shadow is a security design: /etc/passwd is world-readable (lots of programs need to map UIDs to names), so the actual password hashes live in /etc/shadow, which only root can read. The x in the second field of /etc/passwd literally means "the password is over in shadow." You *can* edit these files directly, but use vipw and vigr — they take a lock so two edits can't collide and they validate syntax before saving.

Creating users

What it is: useradd creates an account; passwd sets its password.

Why it matters: "create user X with these properties" is the most common single task in this domain, and the flags are exactly the properties the task will specify.


useradd -u 1500 -G engineering -s /bin/bash -m alice    # the common form
echo 'TempPass123!' | passwd --stdin alice              # set password non-interactively

# A system/service account: no login, no home, low UID
useradd -r -s /sbin/nologin -d /var/lib/deploy -M deploy

# Verify
id alice
getent passwd alice

The flags map directly to task language: -u sets the UID, -G adds *supplementary* groups, -s the login shell, -m creates the home directory (and -M skips it). The -r flag makes a *system account* — a low UID from the system range, used for services rather than people, typically paired with -s /sbin/nologin so nobody can log in as it. passwd --stdin is a Red Hat convenience for scripting password sets non-interactively; it's non-portable but the exam allows it. Always id alice afterward to confirm the UID and group memberships landed as intended.

Flag cheat sheet: -u UID · -g primary group · -G supplementary groups · -s shell · -d home dir · -m create home / -M skip · -c comment (GECOS) · -e YYYY-MM-DD expiration · -r system account.

Password aging

What it is: chage ("change age") controls password lifetime policy — how often a password must change, minimum interval, warning period, and account expiration.

Why it matters: "configure the account to require a password change every 90 days" is a precise, scored task, and chage is the tool built for it.


chage -l alice                         # view current aging settings
chage -M 90 -m 1 -W 14 alice           # max 90 days, min 1 between changes, warn 14
chage -d 0 alice                       # force a password change at next login
chage -E 2025-12-31 alice              # account expires on this date

Read the flags as policy knobs: -M is the *maximum* days a password is valid before it must change, -m the *minimum* days between changes (stops users from immediately changing back), -W the warning window before expiry. chage -d 0 is a neat trick — it sets the "last changed" date to epoch zero, which forces a change at next login (great for handing out temporary passwords). chage -l shows you the current state to verify your work.

Group operations

What it is: commands to create groups and manage membership — and the one flag (-a) that prevents you from accidentally wiping someone's group list.

Why it matters: the append-vs-replace distinction is the single most common point-loser in this domain.


groupadd -g 2000 engineering           # create with a specific GID
groupmod -n eng engineering            # rename
groupdel old-group                     # delete

# Add a user to a supplementary group WITHOUT removing their others:
usermod -aG engineering alice          # the -a (append) is CRITICAL
gpasswd -a alice engineering           # alternative way to append
gpasswd -d alice engineering           # remove from a group

Here is the trap, spelled out: usermod -G engineering alice *replaces* alice's entire supplementary group list with just engineering — silently dropping every other group she was in. usermod -aG engineering alice *appends* (the -a = add). The exam loves this because the wrong version looks like it worked. Burn -aG into muscle memory; never type usermod -G for a single group add. gpasswd -a is the alternative that's append-only by design.

sudo configuration

What it is: sudo grants specific users or groups the ability to run commands as root. It's configured in /etc/sudoers and, preferably, drop-in files under /etc/sudoers.d/.

Why it matters: "give group X sudo access to Y" is a common task, and a syntax error in sudoers can lock you out of root entirely — which is why the safe-editing tooling matters.


cat > /etc/sudoers.d/engineering <<'EOF'
%engineering ALL=(ALL) NOPASSWD: /usr/sbin/dnf, /usr/bin/systemctl
EOF
visudo -cf /etc/sudoers.d/engineering   # syntax-check the file
chmod 0440 /etc/sudoers.d/engineering   # required permissions

Never edit /etc/sudoers directly without visudo — it validates syntax on save and refuses to write a broken file, because a malformed sudoers line can leave nobody able to use sudo. Drop-in files in /etc/sudoers.d/ are the clean modern approach: one file per grant, easy to add and remove. Reading the rule: %engineering means "the group engineering" (the % prefix; without it the entry is for a single user). ALL=(ALL) means "on any host, may run as any user." NOPASSWD: followed by a command list limits the grant to those commands and skips the password prompt. The file must be mode 0440 or sudo ignores it.

Locking accounts and root lockdown

What it is: passwd -l / usermod -L disable password login for an account by invalidating the stored hash; -u/-U reverse it.

Why it matters: "lock this account" and "disable root password login" are direct tasks, and the lab's root-lockdown pattern mirrors real hardening.


passwd -l alice          # lock (prepends ! to the hash in /etc/shadow)
passwd -u alice          # unlock
passwd -S alice          # status: LK = locked, PS = password set
usermod -L alice         # same as passwd -l

# Root lockdown — but make sure a sudo-capable user exists FIRST
passwd -l root

Locking works by prefixing the password hash with ! so no password can match — the account still exists, it just can't authenticate by password. passwd -S reports the state at a glance. The root-lockdown line is the dangerous one: disabling root's password is good hardening, but only after you've confirmed another user has working sudo access — otherwise you've locked yourself out of administrative access entirely.

Common pitfalls

  • usermod -G grp alice without -a WIPES alice's other supplementary groups. Always use -aG for adding a single group.
  • useradd without -m doesn't create a home directory — the user can log in but lands in / with no home. Add -m unless a service account is intended.
  • passwd --stdin is Red Hat/AlmaLinux-specific (non-portable), but the exam runs on RHEL so it's fine there.
  • Editing /etc/sudoers without visudo risks a syntax error that disables sudo for everyone. Use visudo or drop-ins with visudo -cf.
  • Locking root before confirming a working sudo user → you lock yourself out of admin entirely.
  • Custom UIDs need to be consistent across servers when NFS is involved — the wire enforces UIDs, not names.

Exam tips

  • After any user or group change, run id <user> to verify UID, primary group, and supplementary groups in one shot.
  • For "temporary password, must change on first login," combine passwd --stdin with chage -d 0.
  • Drop-in sudoers files (/etc/sudoers.d/) are safer and clearer than editing the main file — and remember the 0440 mode or sudo silently ignores them.
Next: Module 8 — Security (firewalld + SELinux + ACLs).