Lab 05 — PAM & Password Policy: OS Authentication Hardening¶

Overview¶

PAM — Pluggable Authentication Modules — is the Linux authentication framework that sits between every login-aware application and the actual authentication logic. Instead of every program implementing its own password check, all authentication flows through a configurable PAM stack.

In this lab you will:

• Explore PAM configuration files and understand module types and control flags
• Install and configure libpam-pwquality to enforce strong password requirements
• Read and interpret every field in /etc/shadow
• Configure password aging with chage
• Lock and unlock accounts with passwd -l / passwd -u

Part 1 — PAM Architecture¶

Step 1.1 — Launch the Lab Container¶

docker run --rm -it ubuntu:22.04 bash

All steps in Parts 1–4 run inside this container unless stated otherwise.

Step 1.2 — Explore PAM Configuration Files¶

ls /etc/pam.d/
cat /etc/pam.d/common-auth
cat /etc/pam.d/common-password

Expected output: A directory listing of per-service PAM files (login, su, sshd, common-auth, common-password, etc.). common-auth will show lines referencing pam_unix.so.

Key concepts — PAM module types:

Key concepts — PAM control flags:

📸 Screenshot checkpoint 05a: Full terminal showing ls /etc/pam.d/ output AND cat /etc/pam.d/common-auth content in the same window.

Step 1.3 — Inspect a Multi-Module PAM Stack¶

cat /etc/pam.d/su

Expected output: Several module lines in the format:

module_type   control_flag   module_path   [options]

Each line is one step in the authentication stack. PAM evaluates them top-to-bottom, and the combination of control flags determines the final allow/deny decision.

Part 2 — Password Quality¶

Step 2.1 — Install and Inspect pwquality¶

apt-get update -qq && apt-get install -y -qq libpam-pwquality 2>/dev/null
cat /etc/security/pwquality.conf

Expected output: A file that is almost entirely comments. The effective defaults include minlen = 8 (minimum 8 characters). All other quality options are inactive until explicitly enabled.

Step 2.2 — Test Default Password Quality¶

useradd -m testuser
echo 'testuser:abc' | chpasswd 2>&1
echo 'testuser:Str0ng!P@ss99' | chpasswd && echo 'Strong password accepted'

Expected output:

• abc → BAD PASSWORD: The password is shorter than 8 characters
• Str0ng!P@ss99 → Strong password accepted

📸 Screenshot checkpoint 05b: Terminal showing the weak password rejection message (BAD PASSWORD).

Step 2.3 — Configure a Stricter Policy¶

cat > /etc/security/pwquality.conf << 'EOF'
minlen = 12
dcredit = -1
ucredit = -1
lcredit = -1
ocredit = -1
EOF
cat /etc/security/pwquality.conf

Parameter reference:

📸 Screenshot checkpoint 05c: The cat /etc/security/pwquality.conf output showing all five directives.

Step 2.4 — Test the New Policy¶

useradd -m user2 2>/dev/null || true
echo 'user2:Short1!' | chpasswd 2>&1
echo 'user2:Str0ng!P@ssw0rd99' | chpasswd && echo 'Policy-compliant password accepted'

Expected output: Short1! is rejected (too short / missing character classes); Str0ng!P@ssw0rd99 is accepted.

Part 3 — Account Lockout and /etc/login.defs¶

Step 3.1 — Install and Inspect faillock¶

apt-get update -qq && apt-get install -y -qq libpam-faillock 2>/dev/null
faillock --user testuser

faillock tracks failed authentication attempts per user. After a configurable threshold (default 3 failures in 15 minutes in /etc/security/faillock.conf), the account is temporarily locked.

Step 3.2 — System-Wide Password Aging Defaults¶

grep -E '^PASS_MAX_DAYS|^PASS_MIN_DAYS|^PASS_WARN_AGE|^LOGIN_RETRIES' /etc/login.defs

Expected output:

PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_WARN_AGE   7
LOGIN_RETRIES   5

These are defaults for new accounts. They do not retroactively change existing accounts — use chage for that.

Step 3.3 — Apply Password Aging to testuser¶

chage -M 90 -W 14 testuser
chage -l testuser

Expected output: Maximum number of days between password change: 90 and Number of days of warning before password expires: 14.

📸 Screenshot checkpoint 05d: The full chage -l testuser output clearly showing the 90-day maximum and 14-day warning period.

Part 4 — /etc/shadow Deep Dive¶

Step 4.1 — Read and Annotate the Shadow Entry¶

grep testuser /etc/shadow

Expected output (example):

testuser:$y$j9T$...:19900:0:90:14:::

The nine colon-separated fields:

📸 Screenshot checkpoint 05e: The raw /etc/shadow entry for testuser. Annotate each field in your screenshot (draw arrows or add labels).

Step 4.2 — Lock and Unlock the Account¶

passwd -l testuser
grep testuser /etc/shadow | cut -d: -f2 | head -c 5
echo '(! prefix = locked)'
passwd -u testuser
grep testuser /etc/shadow | cut -d: -f2 | head -c 5
echo '(hash restored = unlocked)'

Expected output:

!$y$j                  ← first 5 chars of locked hash
(! prefix = locked)
$y$j9                  ← first 5 chars of unlocked hash
(hash restored = unlocked)

passwd -l prepends ! to the hash. PAM sees that ! and refuses to authenticate — the stored hash can never match any password the user supplies. passwd -u removes the !, restoring the original hash.

📸 Screenshot checkpoint 05f: Both the locked state (! prefix visible) and the unlocked state in the same terminal session.

Cleanup¶

Exit the container (type exit if still inside), then prune Docker resources:

docker system prune -f

Assessment¶

Screenshot Checklist¶

Reflection Questions¶

Q1. PAM stands for Pluggable Authentication Modules. What does pluggable mean in this context? Give a concrete example of how an organisation could add multi-factor authentication to the Linux login command without changing any application source code.

Q2. In Step 2.2, the password abc was rejected as too short. Why is minimum password length the single most impactful password policy control? Quantify how increasing minimum length from 8 to 12 characters affects the time required to exhaust all possible passwords through brute force (assume a modest 10 billion guesses per second).

Q3. /etc/shadow stores hashed passwords rather than plaintext. Why does this matter even though the file is only readable by root? Describe the specific steps an attacker would take after gaining read access to /etc/shadow — what tools would they use and what would they look for?

Q4. You locked testuser's account with passwd -l and observed ! prepended to the password hash. What class of attack does account locking defend against? Why might a security incident response team choose to lock a compromised account rather than immediately delete it?