User and Group Management

Why User and Group Management Matters

Every Linux system enforces access control through user accounts and groups. In a cybersecurity role you will create accounts for new staff, restrict or remove access when people leave, and audit existing accounts for misconfigurations. The principle of least privilege — giving each account only the access it needs — is a core concept tested on the ISC2 CC, CompTIA Security+, and CompTIA CySA+ exams and enforced in CIS Benchmarks.

Key Files: /etc/passwd, /etc/shadow, and /etc/group

/etc/passwd stores one line per account. Each line has seven colon-separated fields: username, a placeholder `x` (password hash moved to shadow), UID, GID, GECOS comment, home directory, and login shell. Root always has UID 0. Any account with UID 0 that is not root is a critical vulnerability.

/etc/shadow stores the actual password hash along with aging fields: last change date, minimum days, maximum days, warning days, inactivity days, and expiry date. Only root (or processes with the `shadow` group) can read this file. A blank or `!` hash entry signals a locked or passwordless account — the latter is a serious weakness.

/etc/group lists group names, a placeholder, GID, and member usernames. The `sudo` group (or `wheel` on some distributions) grants administrative privilege. Membership should be audited regularly.

Creating Accounts: useradd

The `useradd` command creates a new account. Common options:

• `-m` — create the home directory
• `-s /bin/bash` — set the login shell
• `-G groupname` — add to a supplementary group at creation
• `-c "Full Name"` — add a GECOS comment

Example: `sudo useradd -m -s /bin/bash -G developers -c "Alex Rivera" arivera`

After creating the account, set a password immediately: `sudo passwd arivera`. Leaving a password unset is a security risk — the CIS Ubuntu Linux Benchmark recommends that all interactive accounts have a password or be explicitly locked.

Modifying Accounts: usermod

`usermod` changes an existing account. Key options:

• `-aG groupname` — append the user to a supplementary group (omitting `-a` replaces all groups)
• `-L` — lock the account (prepends `!` to the hash in /etc/shadow)
• `-U` — unlock
• `-s /sbin/nologin` — set a non-interactive shell to block login
• `-l newname` — rename the account

When revoking sudo access, remove the account from the sudo group: `sudo gdeluser username sudo` or `sudo usermod -G "" username` after confirming other group memberships.

Password Aging: chage

`chage` manages the password aging fields in /etc/shadow.

• `-M 90` — maximum password age (days)
• `-m 1` — minimum age before a change is allowed
• `-W 14` — warn the user 14 days before expiry
• `-E 2025-12-31` — set an absolute account expiry date
• `-l username` — list current aging settings
• `-d 0` — force a password change on next login

The CIS Ubuntu Linux Benchmark provides specific recommended values for maximum password age and warning periods. Always reference the current benchmark version for your distribution.

Offboarding Safely

When an employee leaves, follow a consistent runbook to avoid data loss and unauthorized access:

1. Lock the account — `sudo usermod -L username` prevents login immediately.

2. Expire the password — `sudo chage -E 0 username` sets the expiry to the epoch, blocking any re-enable without admin action.

3. Revoke sudo — remove the account from the sudo/wheel group.

4. Archive the home directory — `sudo tar -czf /archive/username-$(date +%F).tar.gz /home/username` preserves files for HR or legal review before deletion.

5. Delete the account — `sudo userdel -r username` removes the account and its home directory. Use `-r` only after confirming the archive is complete.

Document every command in your runbook. In regulated environments, an incomplete offboarding record is itself a finding.

Group Management: groupadd and gpasswd

`groupadd rolename` creates a new group. `gpasswd -a username groupname` adds a member; `gpasswd -d username groupname` removes one. Groups enforce role-based access control (RBAC) — a concept central to all three target credentials.

Auditing for Weaknesses

Common misconfigurations to look for:

• Duplicate UID 0 — `awk -F: '($3=="0"){print $1}' /etc/passwd` should list only `root`.
• Blank password hash — `sudo awk -F: '($2==""){print $1}' /etc/shadow` lists accounts with no password.
• Non-expiring accounts — `sudo chage -l username` reveals accounts with no maximum age set.
• Unnecessary sudo members — `getent group sudo` shows who has administrative access.

When you find a weakness, document it, apply the fix, and verify with the same command that revealed it.

Safety Notes

Always work in a dedicated lab VM — never practice account deletion or shadow file edits on a production system. Take a snapshot before the lab. Running commands as root carries risk; use `sudo` and verify each command before pressing Enter. Keep a copy of /etc/passwd and /etc/shadow before intentionally introducing weaknesses so you can restore them. Treat any exported shadow file as sensitive and delete lab copies securely when finished.