Loading...

VONDS ©

Lab 147: RHCSA User + Group Admin — tsuli Account Workflow

Back to Lab Index

Provision a short-lived contractor account (tsuli), confirm NSS identity and shadow visibility, add correct supplemental groups, validate permissions on core auth databases, then cleanly remove the account and home directory.

users security core

Scenario

You need to provision a contractor account, tsuli , for documentation updates. The account must be added to the editor and devops teams. After provisioning, Ops wants a quick audit of NSS user/group records and core authentication database file permissions before access is approved.

Operator context

This workflow prioritizes repeatable verification: prove the account exists via NSS, validate access-relevant group membership, and confirm the system’s auth databases are protected with correct permissions.

Objective

  • Ensure required groups exist: editor and devops.
  • Create tsuli with a home directory.
  • Verify NSS records for passwd, group, and shadow.
  • Add tsuli to editor and devops without overwriting groups.
  • Validate permissions on /etc/passwd, /etc/group, /etc/shadow, /etc/gshadow.
  • Remove the account and home directory (cleanup).

Concepts

  • Group prerequisites and idempotent group creation with groupadd -f .
  • User provisioning with a managed home directory ( useradd -m ).
  • NSS-backed validation using getent (authoritative view of identity sources).
  • Identity verification and group visibility using id and id -gn .
  • Safe group membership changes using usermod -aG (avoid clobbering existing groups).
  • Authentication database protection: expected permissions on /etc/*shadow* .
  • Clean teardown using userdel -r for lab hygiene.

Walkthrough

Step 1 : Ensure editor and devops groups exist.
Command 
sudo groupadd -f editor && sudo groupadd -f devops

Use -f to make the command safe to rerun. This prevents a failure if the groups already exist and keeps the workflow repeatable.

Step 2 : Create the tsuli user with a home directory.
Command 
sudo useradd -m tsuli

-m ensures a home directory is created. This is a common expectation for interactive contractor accounts and avoids “account exists but no home” drift.

Step 3 : Verify tsuli exists in the passwd database via NSS.
Command 
getent passwd tsuli

getent queries NSS. This is the reliable “does the system resolve this identity” check, regardless of whether the source is local files, LDAP, SSSD, or another provider. 

tsuli:x:1002:1002:tsuli:/home/tsuli:/bin/bash
Step 4 : Confirm identity details and primary group name.
Commands 
id tsuli
id -gn tsuli

id shows UID/GID and supplementary groups. Use id -gn to print only the primary group name for quick checks and scripting. 

uid=1002(tsuli) gid=1002(tsuli) groups=1002(tsuli)
tsuli
Step 5 : Review tsuli’s shadow entry via NSS.
Command 
sudo getent shadow tsuli

Shadow data is privileged. This step confirms that the account resolves in the shadow database and reinforces the access boundary around sensitive auth material. 

tsuli:!!:19700:0:99999:7:::
Step 6 : Add tsuli to editor and devops (supplementary groups).
Command 
sudo usermod -aG editor,devops tsuli

-aG appends groups. Omitting -a is a common failure mode that can overwrite existing supplementary groups.

Verify 
id tsuli
uid=1002(tsuli) gid=1002(tsuli) groups=1002(tsuli),1005(editor),1006(devops)
Step 7 : Verify editor group membership details via NSS.
Command 
getent group editor

This confirms NSS group resolution and shows whether tsuli is listed in the group’s member field. 

editor:x:1005:tsuli
Step 8 : Inspect permissions on core auth databases.
Command 
ls -l /etc/passwd /etc/group /etc/shadow /etc/gshadow

These file modes are a baseline security control. Expect world-readable identity databases ( /etc/passwd , /etc/group ) and root-only shadow databases ( /etc/shadow , /etc/gshadow ). 

-rw-r--r--. 1 root root   ... /etc/passwd
-rw-r--r--. 1 root root   ... /etc/group
-rw-------. 1 root root   ... /etc/shadow
-rw-------. 1 root root   ... /etc/gshadow
Step 9 : Remove the contractor account and home directory (cleanup).
Command 
sudo userdel -r tsuli

-r removes the user’s home directory and mail spool. This keeps the lab environment clean and prevents leftover state from contaminating future reps.

Common breakpoints

getent shadow returns “Permission denied”

Shadow data is privileged. Run the command with sudo and confirm you have appropriate administrative access.

usermod applied groups but editor/devops not shown in id

Confirm you used -aG and the exact group names. Then rerun id tsuli and validate NSS group output with getent group editor and getent group devops .

Forgot -a and overwrote supplementary groups

Omitting -a can replace existing supplementary groups. Re-apply with usermod -aG and verify again with id .

/etc/shadow permissions are not 600

Treat this as a security issue. Do not “work around it.” Escalate and correct file ownership and permissions using approved policy before enabling access for any account.

userdel -r fails due to running processes

If the user is logged in or has active processes, logout and stop sessions first, then retry userdel -r .

Cleanup checklist

Remove the user and confirm the account no longer resolves via NSS. This verifies that both identity records and filesystem state (home directory) were cleaned up.

Commands 
sudo userdel -r tsuli
getent passwd tsuli
getent group editor
Success signal

getent passwd tsuli returns no output, and the user is no longer listed as a member in getent group editor output.

Reference

  • groupadd -f <group> : Creates a group and does not fail if the group already exists.
    • -f : Forces idempotent behavior (no error if present).
  • useradd -m <user> : Creates a user and ensures a home directory exists.
    • -m : Creates the home directory.
  • getent passwd <user> : Queries NSS for the user’s passwd entry.
  • getent shadow <user> : Queries NSS for the user’s shadow entry (requires privilege).
  • id <user> : Shows UID, primary GID, and supplementary group membership.
  • id -gn <user> : Prints the user’s primary group name.
    • -g : Selects the primary group.
    • -n : Prints the name instead of the numeric ID.
  • usermod -aG <group1,group2> <user> : Appends the user to supplementary groups without overwriting existing groups.
    • -a : Appends (do not replace existing supplementary groups).
    • -G : Sets the supplementary group list.
  • getent group <group> : Queries NSS for group details, including membership.
  • ls -l /etc/passwd /etc/group /etc/shadow /etc/gshadow : Displays permissions and ownership for core auth databases.
  • userdel -r <user> : Removes a user and the user’s home directory.
    • -r : Removes the home directory and mail spool.