Password policy and MFA

Before you read. Somebody left on Friday. You did the thing you were told to do: passwd -l on their account, ticket closed, offboarding complete.

On Monday the audit log shows them logging in at 07:40, running a deployment, and logging out. The account is still locked. You check twice. It is definitely locked.

What did locking the password actually stop?

Less than the word suggests. Locking makes the stored password hash unmatchable, so nothing typed at a password prompt will ever succeed. It does not remove an SSH key, it does not close a shell, and it does not stop cron running that person’s jobs at 07:40 on Monday.

That is the shape of this whole topic. A password policy is four or five separate controls, enforced by four or five separate mechanisms, configured in four or five different files, and the interesting failures all come from believing that one of them covers more ground than it does.

Some words you will need

ageing

The dates and intervals stored per account that decide when a password must change and when the account stops working. Fields three to eight of /etc/shadow.

composition rule

A requirement that a password contain particular classes of character. "One upper, one digit, one symbol."

credit

In pam_pwquality, how much a class of character is worth toward the length requirement. A negative value turns the credit into a requirement.

history

Previous password hashes kept so a new password can be rejected for being an old one. Stored in /etc/security/opasswd.

lockout

Refusing further authentication attempts after a number of consecutive failures. Distinct from a locked password.

locked

A hash made unmatchable by prefixing it with !. Password authentication cannot succeed; nothing else is affected.

TOTP

Time-based one-time password. A six-digit code derived from a shared secret and the current time, changing every thirty seconds.

nologin

A program that prints a message and exits non-zero. Used as a login shell to give an account no interactive session.

What breaks without this

You close an account and it is not closed. Locking the password leaves key authentication, scheduled jobs, and existing sessions completely untouched, which is the single most common incomplete offboarding there is.

Your new policy applies to nobody. /etc/login.defs sets defaults at account creation. Editing it changes nothing for the four hundred accounts that already exist, and nothing warns you.

You lock yourself out. A lockout policy that counts root’s failures, applied to a machine you reach only over SSH, is a control and a self-inflicted outage wearing the same clothes.

The policy gets written on a sticky note. Fourteen characters, one of each class, changed every ninety days, no reuse: the reachable human response is Summer2026! becoming Autumn2026!, on paper, under the keyboard. A rule nobody can follow is not a control.

Four controls, three moments

Almost every confusion in this topic comes from not knowing when a given control runs. There are three moments in an account’s life, and each one consults a different thing.

Read the arrows. Two of the three moments write to /etc/shadow and one reads from it. That is why a change to login.defs today shows up in nothing you can see: it will affect the next account created and no other.

Nothing in that table is set in the same place as anything else in it, and the exam expects you to be able to name the right one from a symptom.

The defaults, and why they are only defaults

Start with what a machine ships with:

# AlmaLinux 10.2, x86_64
$ grep -E '^PASS_|^UMASK|^ENCRYPT_METHOD' /etc/login.defs
UMASK		022
PASS_MAX_DAYS	99999
PASS_MIN_DAYS	0
PASS_MIN_LEN	8
PASS_WARN_AGE	7
PASS_CHANGE_TRIES	5
PASS_ALWAYS_WARN	yes
ENCRYPT_METHOD YESCRYPT

PASS_MAX_DAYS 99999 is the default on every mainstream distribution, and 99999 days is about 273 years. Out of the box, passwords never expire. Everything about expiry in this topic is a change from that.

The three that matter:

ENCRYPT_METHOD YESCRYPT decides the hash algorithm for passwords set from here on. It is the current default on AlmaLinux 10 and Debian 13; older machines say SHA512. Changing it does nothing retroactively either, each account migrates to the new algorithm the next time its password is set, which you can see in the $y$ versus $6$ prefix from lesson 28.

PASS_MIN_LEN is the interesting trap in that file. AlmaLinux 10 still ships the line, it looks exactly like the length policy you were asked to configure, and on a machine using PAM nothing reads it, length is pam_pwquality’s job, several sections down. The clearest evidence is that current login.defs(5) documents PASS_MAX_DAYS, PASS_MIN_DAYS, and PASS_WARN_AGE and does not mention PASS_MIN_LEN at all. Setting it to 14 and reporting the policy as implemented is a real and frequent mistake.

Ageing, field by field

A brand new account inherits those defaults, and chage -l is how you read them back:

# AlmaLinux 10.2, x86_64
$ useradd sam; chage -l sam
Last password change					: Aug 08, 2026
Password expires					: never
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 0
Maximum number of days between password change		: 99999
Number of days of warning before password expires	: 7

Seven lines, and they are the six ageing fields of /etc/shadow rendered as dates instead of day counts. chage -l is the tool to reach for, not grep on the shadow file, because it does the epoch arithmetic for you and it does not require root to read your own account.

Now apply a policy to that account:

# AlmaLinux 10.2, x86_64
$ chage -M 90 -m 7 -W 14 sam; chage -l sam
Last password change					: Aug 08, 2026
Password expires					: Nov 06, 2026
Password inactive					: never
Account expires						: never
Minimum number of days between password change		: 7
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 14

Password expires became a real date, computed from the last change plus 90 days. Nothing else moved.

-m exists for a reason and it is not the one people assume. Its purpose is to stop somebody defeating password history by changing their password eleven times in a row to get back to the one they like. Its cost is that a person whose password has just been compromised cannot change it, and you have to clear the minimum before they can. Set it to 1 if you set it at all; 7 is a support ticket waiting to happen.

-E is a different animal from -M and the difference is the whole of the next section:

# AlmaLinux 10.2, x86_64
$ chage -E 2026-12-31 sam; chage -l sam
Last password change					: Aug 08, 2026
Password expires					: Nov 06, 2026
Password inactive					: never
Account expires						: Dec 31, 2026
Minimum number of days between password change		: 7
Maximum number of days between password change		: 90
Number of days of warning before password expires	: 14

Two independent expiry dates on one account. The November one ends the password; the person changes it and carries on. The December one ends the account, and nothing they do at a prompt will help.

chage -E is what a contractor’s account should have from the day it is created. An end date set in advance costs nothing and closes the account on time whether or not anybody remembers.

Locked, shell-disabled, and expired are three different things

This is the section the opening question was about, and the three states get conflated constantly. Start from a normal account:

# AlmaLinux 10.2, x86_64
$ grep '^sam:' /etc/shadow; passwd -S sam
sam:$y$j9T$i3.3Rdlm9PuNsDxpu/xfu/$fp6oK8oAltwRX4OtNcXTLDckNNPsGBLbr79KFpndBu.:20673:0:99999:7:::
sam P 2026-08-08 0 99999 7 -1

Two views of the same account. The shadow line is the raw record; passwd -S is the summary, and its seven fields are worth learning because they are the fastest read there is:

Field two is the one that matters, and it has three values.

# AlmaLinux 10.2, x86_64
$ passwd -l sam; grep '^sam:' /etc/shadow; passwd -S sam
passwd: password changed.
sam:!$y$j9T$i3.3Rdlm9PuNsDxpu/xfu/$fp6oK8oAltwRX4OtNcXTLDckNNPsGBLbr79KFpndBu.:20673:0:99999:7:::
sam L 2026-08-08 0 99999 7 -1

One character. The hash is byte-for-byte what it was, with ! in front of it. No password hashes to a string starting with !, so the comparison can never match, and the original is still there, which is why unlocking restores the old password rather than clearing it:

# AlmaLinux 10.2, x86_64
$ passwd -u sam; grep '^sam:' /etc/shadow; passwd -S sam
passwd: password changed.
sam:$y$j9T$i3.3Rdlm9PuNsDxpu/xfu/$fp6oK8oAltwRX4OtNcXTLDckNNPsGBLbr79KFpndBu.:20673:0:99999:7:::
sam P 2026-08-08 0 99999 7 -1

Note passwd: password changed. on both. That message is what passwd prints for any modification of the field, and it is not evidence that a password was set. Reading it as such is a classic way to convince yourself an offboarding worked.

There is a fourth state hiding here, and it is the dangerous one:

# AlmaLinux 10.2, x86_64
$ passwd -d sam; grep '^sam:' /etc/shadow; passwd -S sam
passwd: password changed.
sam::20673:0:99999:7:::
sam NP 2026-08-08 0 99999 7 -1

passwd -d empties the field, and an empty password field does not mean “no login”. It means no password required. passwd -S reports NP, and depending on how pam_unix is configured, nullok is in the shipped AlmaLinux stack, that is an account anybody can walk into. -d and -l are one letter apart and opposite in effect. awk -F: '$2 == "" {print $1}' /etc/shadow is the check that finds them.

Locking is also, quietly, the normal state of most of the machine:

# AlmaLinux 10.2, x86_64
$ passwd -Sa | head -12
root L 2025-06-05 0 99999 7 -1
bin L 2025-06-05 0 99999 7 -1
daemon L 2025-06-05 0 99999 7 -1
adm L 2025-06-05 0 99999 7 -1
lp L 2025-06-05 0 99999 7 -1
sync L 2025-06-05 0 99999 7 -1
shutdown L 2025-06-05 0 99999 7 -1
halt L 2025-06-05 0 99999 7 -1
mail L 2025-06-05 0 99999 7 -1
operator L 2025-06-05 0 99999 7 -1
games L 2025-06-05 0 99999 7 -1
ftp L 2025-06-05 0 99999 7 -1

Every system account is L, including root on this image. passwd -Sa is one command for the whole machine, and piping it to awk '$2 == "P"' produces the list of accounts on this box that can be logged into with a password, which is a much shorter and much more interesting list than /etc/passwd.

The second state: a shell that is not a shell

A working baseline first, so the difference is unambiguous:

# AlmaLinux 10.2, x86_64
$ su - sam -c id; echo "rc=$?"
uid=1000(sam) gid=1000(sam) groups=1000(sam)
rc=0

Now the same command against an account whose shell has been replaced:

# AlmaLinux 10.2, x86_64
$ grep '^sam:' /etc/passwd; passwd -S sam; su - sam -c id; echo "rc=$?"
sam:x:1000:1000::/home/sam:/sbin/nologin
sam P 2026-08-08 0 99999 7 -1
This account is currently not available.
rc=1

Read the second line before the third. passwd -S says P: the password is perfectly usable and authentication succeeded. What failed is the shell. /sbin/nologin printed its message and exited 1, and id never ran.

That is the correct state for a service account, and it is not an authentication control. The credential still works, and depending on configuration SFTP, scp, and SSH port forwarding may still function, because none of them needs an interactive shell.

The third state: the account itself has ended

Account expiry is checked in a different PAM phase from the password, and that one structural fact produces a result most people get wrong.

# AlmaLinux 10.2, x86_64
$ chage -E 2020-01-01 sam; chage -l sam | head -3; su - sam -c id; echo "rc=$?"
Last password change					: Aug 08, 2026
Password expires					: never
Password inactive					: never
uid=1000(sam) gid=1000(sam) groups=1000(sam)
rc=0

It runs, and the account is genuinely expired. This is not a bug and it is not evidence that chage -E failed. It is the account stack in /etc/pam.d/su on the RHEL family, whose first line is:

account		sufficient	pam_succeed_if.so uid = 0 use_uid quiet

sufficient plus a condition that root satisfies means the account phase returns success immediately and pam_unix, the module that would have read the expiry field, is never reached. Root’s su is exempt by design, so testing account expiry as root, with su, gives a false negative every time.

Test it the way a person would arrive instead: over SSH, at a console login, or with su from an unprivileged account. Those all run pam_unix in the account phase, and those all get refused.

And that is the point worth carrying out of this section. Expiry is checked after authentication has already succeeded, so it does not matter which credential was used to get there. A password, an SSH key, a Kerberos ticket, all of them reach the account phase, and all of them are refused there. That is what makes it the strongest of the three states, and what makes su as root the worst possible way to verify it.

Which gives the table the exam is testing:

The bold column is the answer to the question this topic opened with. Locking prefixes the password hash; SSH public key authentication never looks at the password hash. Somebody with an entry in ~/.ssh/authorized_keys is entirely unaffected by passwd -l, which is why the audit log shows them logging in at 07:40 on Monday.

Say it as a rule: locking is not closing. Closing an account is a sequence, and the order matters because each step can be undone by something still running:

sudo chage -E 0 sam                     # expired: refused at the account phase
sudo passwd -l sam                      # locked: refused at the auth phase
sudo usermod -s /sbin/nologin sam       # no interactive shell if either is bypassed
sudo mv ~sam/.ssh/authorized_keys ~sam/.ssh/authorized_keys.revoked
sudo crontab -r -u sam                  # scheduled jobs do not need a login
sudo loginctl terminate-user sam        # kill what is already connected

chage -E 0 first, because it is the one that holds regardless of credential. Everything after it is defence in depth against a path you did not think of.

Strength, and the module that enforces it

Length and composition are not in login.defs and not in /etc/shadow. They are a PAM module that runs when a password is set, and on the RHEL family the line is already in the shipped stack:

password    requisite                                    pam_pwquality.so
password    sufficient                                   pam_unix.so yescrypt shadow nullok use_authtok

requisite before sufficient is the design. pam_pwquality gets the proposed password first and can refuse it outright; only if it passes does pam_unix hash and store it. use_authtok on the pam_unix line means “use the password the previous module already collected and approved”, and removing it silently disables the whole check by making pam_unix ask again.

libpwquality ships a way to ask the same question without changing anything:

# AlmaLinux 10.2, x86_64
$ for p in password Passw0rd correct-horse-battery-staple; do printf "%s\n" "$p" | pwscore; echo "rc=$?"; done
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word
rc=1
Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word
rc=1
100
rc=0

Passw0rd failing is the point of the whole section. It satisfies every composition rule anybody has ever written (upper, lower, digit, eight characters) and it is rejected, because substituting a zero for an o is the first thing any cracking tool tries and the dictionary check knows it. Meanwhile correct-horse-battery-staple scores 100 with no capital letter, no digit, and no symbol.

That is the empirical case against composition rules in a single transcript: they measure the wrong thing. Length and unpredictability are what resist guessing; character classes measure how annoyed the user was.

pwscore is worth having in your hands for another reason: it is the only way to test a policy change without setting a real password on a real account. Edit pwquality.conf, run pwscore against half a dozen realistic candidates, and you know what you have done before anybody else finds out.

Reuse, and the file that has to exist

Stopping somebody cycling back to last quarter’s password is a separate module again:

password requisite pam_pwquality.so retry=3
password required  pam_pwhistory.so use_authtok remember=10
password sufficient pam_unix.so yescrypt shadow use_authtok

pam_pwhistory stores previous hashes in /etc/security/opasswd and refuses a new password matching any of the last remember entries. Three things about it are worth knowing before you add the line.

It only remembers from the moment you enable it. The file starts empty, so on the day you set remember=10 every user may still set the password they have been using for two years. Nothing is retroactive.

Root is exempt unless you say otherwise, the same shape as enforce_for_root. A password set by root for another user bypasses the history check by default, which is exactly the path a helpdesk reset takes.

It needs a minimum age beside it, and the age needs to be small. Without chage -m, history is defeated by changing the password eleven times in one sitting; with -m 7, somebody whose password has just leaked cannot replace it. One day is the setting that survives both arguments.

pam_unix has its own remember= option that predates the separate module and writes to the same file. Either works; having both in one stack double-counts confusingly, so pick one.

Lockout after repeated failures

Guessing a password takes attempts. pam_faillock counts them and stops accepting more:

# AlmaLinux 10.2, x86_64
$ authselect enable-feature with-faillock; grep faillock /etc/pam.d/system-auth
auth        required                                     pam_faillock.so preauth silent
auth        required                                     pam_faillock.so authfail
account     required                                     pam_faillock.so

One command, three lines added in the right places. That is the supported way to do it on the RHEL family, and the alternative is putting those three lines into a generated file by hand and having them removed by the next profile apply.

Then it counts. Two failed su attempts, and the tally:

# AlmaLinux 10.2, x86_64
$ for i in 1 2; do (sleep 2; echo hunter2) | runuser -u tux -- script -qec "su - root -c id" /dev/null; done; faillock --user root
Password: 
su: Authentication failure
Password: 
su: Authentication failure
root:
When                Type  Source                                           Valid
2026-08-08 18:15:11 TTY   /dev/pts/0                                           V
2026-08-08 18:15:16 TTY   /dev/pts/0                                           V

Two rows, five seconds apart, both marked V for valid. Valid here means “still inside fail_interval, so still counting”. A row that has aged out stays in the file and stops being V. That column is the difference between “this account has failed twice recently” and “this account failed twice last March”, which is the question you actually have when a ticket arrives.

The two commands you will use are reading that table and clearing it:

sudo faillock --user sam
sudo faillock --user sam --reset

--reset is the answer to the support ticket, and it is worth knowing before the ticket arrives, because the command people reach for instead is passwd -u, which does nothing at all to a faillock tally.

/etc/security/faillock.conf holds the numbers, and the man page is explicit that this file is where they belong rather than on the module line:

unlock_time is the setting that decides whether this is a control or an outage. Zero means locked until an administrator resets it, which some standards require and which is a denial of service anybody can trigger against anybody: attempt four bad passwords against every account on the machine and nobody can work. A finite unlock_time costs an attacker almost as much and costs you nothing.

Root is exempt by default and that is a decision, not an oversight. The module documentation says so in as many words: locking root out prevents denial of service, and it is safe on a machine where root logs in only at the console or through su. Turning even_deny_root on is a reasonable choice, and it is the choice that needs a recovery plan beside it.

auth     required       pam_faillock.so preauth
auth     sufficient     pam_unix.so
auth     [default=die]  pam_faillock.so authfail
auth     required       pam_deny.so
account  required       pam_faillock.so

A second factor

A password is one factor: something you know. Adding a second means adding something you have, and the portable answer on Linux is TOTP, the six digits your phone shows, derived from a shared secret and the clock.

The reference implementation is Google’s PAM module, which ships a provisioning tool that generates a secret per user:

google-authenticator -t -d -f -r 3 -R 30 -w 3

That writes ~/.google_authenticator owned by the user, containing the secret, the parameters, and a set of single-use recovery codes. The secret lives in the user’s home directory, which has two consequences people meet later: a home directory on NFS puts every second factor on a file server, and restoring a home directory from backup restores a secret somebody may have rotated.

Enabling it is one line in the PAM stack, and where that line goes is the entire question:

auth required pam_google_authenticator.so nullok

nullok during rollout is not optional. Without it, every user who has not yet run the provisioning tool is locked out the moment you add the line. With it, users without a secret pass through and users with one are challenged, so you can enrol people over a fortnight instead of over a weekend. Removing nullok afterwards is what makes the factor mandatory, and doing that is a decision, not a detail.

KbdInteractiveAuthentication yes
UsePAM yes
AuthenticationMethods publickey,keyboard-interactive

What the evidence says, and what you will be asked to configure

Every mechanism above predates the research on whether it helps, and the guidance has moved a long way from the habits.

NIST SP 800-63B is the document to know by name. Its current position, in short: require a real minimum length and recommend a substantially longer one, allow very long passwords and every printable character, screen candidates against lists of commonly used and compromised passwords, and do not impose composition rules or force periodic changes, change on evidence of compromise instead.

The reasoning is behavioural rather than mathematical. Forced quarterly rotation produces predictable transformations: Autumn2026! follows Summer2026!, and an attacker with one has the next. Composition rules produce Passw0rd, which the transcript above shows being rejected by a dictionary check a composition rule would have waved straight through. Both controls make passwords worse while appearing to make them stronger.

And you will still be asked to configure 90-day expiry, because plenty of compliance regimes mandate it, auditors check for it, and “NIST says otherwise” is not an answer that closes a finding. The two positions coexist like this:

The exam expects the mechanisms regardless of the argument. Knowing that chage -M sets password expiry is testable; knowing that the control is contested is what makes you useful afterwards.

Breach-list checking, and the gap in the base system

The control with the best evidence behind it is the one Linux does not ship. dictcheck uses the cracklib word list, which catches password and Passw0rd and does not catch a password that appeared in a breach corpus last year.

Three practical routes:

• Extend the dictionary. cracklib-format and cracklib-packer compile a cracklib dictionary from a word list, so a trimmed extract of a public breach list can become one. It is coarse, a substring word check rather than an exact-match lookup, and better than nothing on an isolated machine.
• Check at the application layer. The Have I Been Pwned range API answers “has this exact password appeared in a breach” without receiving the password: the client sends only a short prefix of the password’s hash and gets back every matching suffix to compare locally. That is where the control belongs for anything user-facing.
• Push it to the directory. If accounts come from FreeIPA, Active Directory, or LDAP (lesson 38), password policy including breach screening is the directory’s job, and configuring it per host is the wrong layer.

For local Linux accounts, be honest that there is no shipped answer. The realistic control is to have very few accounts with passwords at all, passwd -Sa | awk '$2 == "P"' should be a short list, and keys and a directory for the rest.

Restricted shells, and not being root

The last part of objective 3.4 is not about passwords. It is about how much an authenticated session can do.

nologin is the right shell for anything that is not a person. Database daemons, web servers, and backup agents all need an account and none needs a login. It is the shipped default for system accounts and worth confirming on any account you create for software.

rbash is the restricted shell, and it is worth knowing precisely what it does, because people deploy it expecting a jail:

# AlmaLinux 10.2, x86_64
$ su - sam -c "cd /tmp"; echo "rc=$?"; su - sam -c "PATH=/bin"; echo "rc=$?"
-rbash: line 1: cd: restricted
rc=1
-rbash: line 1: PATH: readonly variable
rc=1

cd refused, PATH refused. It also blocks / in a command name, output redirection, exec, and SHELL and ENV assignment. What it does not do is contain anything the user can start. Any program that can run a subshell (vi, less, awk, find -exec, python) hands back an unrestricted shell in one step, so rbash is only a boundary if the PATH it is given contains a small, audited set of commands and nothing else.

Treat it as a way to shape a session for a cooperative user, not as a security control against an uncooperative one. The real boundaries are the ones from lessons 42 and 44: sudo rules that name specific commands, and SELinux confining what a process may touch regardless of who is running it.

And the standing rule underneath all of it: do not work as root. Log in as yourself, escalate with sudo for the command that needs it, and let the audit trail record who did what. An interactive root session logs one word, root, against every action in it, and PermitRootLogin no in sshd_config from lesson 43 is how most sites make that structural rather than optional.

Across distributions

The row that catches people is the fourth. A Debian or Ubuntu machine with no libpam-pwquality installed enforces no length or complexity policy whatsoever, regardless of what login.defs says, and the machine reports no error because there is no module to report one. dpkg -l libpam-pwquality is a one-line audit that finds it.

The second row is the one that causes silent regressions. Both families generate their PAM stack from something else. On the RHEL family the file says so in its own header; on Debian the mechanism is quieter. Either way, a hand edit is a change with a hidden expiry date.

Prove it

# What will happen to the next account created here
grep -E '^PASS_|^ENCRYPT_METHOD' /etc/login.defs

# What this account actually has, which is not the same question
chage -l alex
sudo passwd -S alex

# Every account and its password state, in one line
sudo passwd -Sa | awk '{print $2}' | sort | uniq -c

# Anybody with no password at all, which should be nobody
sudo awk -F: '$2 == "" {print $1}' /etc/shadow

# Where strength is enforced, and with what numbers
grep -r pwquality /etc/pam.d/
grep -vE '^\s*(#|$)' /etc/security/pwquality.conf

# Test a policy without setting a password
echo 'candidate-password-here' | pwscore

# Reuse, and lockout state
grep -r pwhistory /etc/pam.d/
sudo faillock --user alex

# And the credential none of the above controls
sudo ls -l ~alex/.ssh/authorized_keys

The first and second commands answer different questions and people run only the first. login.defs describes the future; chage -l describes this account. An audit that reads the file and not the accounts will pass a machine where every existing user has PASS_MAX_DAYS 99999.

What trips people up

1. Locking the password and calling the account closed

passwd -l prefixes the hash with !. SSH public key authentication never reads the hash, so a key in authorized_keys still works, cron still runs, and open sessions stay open.

chage -E 0 is the one that holds regardless of credential, because it is checked in PAM’s account phase after authentication has already succeeded. Do that first, then everything else.

2. Editing a generated PAM file

/etc/pam.d/system-auth on the RHEL family carries a header saying it is generated by authselect and will be overwritten. It is telling the truth. /etc/pam.d/common-password on Debian is regenerated by pam-auth-update.

Put numbers in /etc/security/pwquality.conf, use authselect enable-feature for stack changes, and if you genuinely need a custom stack, make a custom profile rather than a hand edit.

3. Setting the maximum age in the wrong file

It is a default applied by useradd at creation. Existing accounts already have their own copy of that number in /etc/shadow and are not consulted again.

Set both: the file for future accounts, chage for the ones that exist. Checking with chage -l on a real account rather than reading the file is what catches it.

4. passwd -d when you meant passwd -l

One letter apart, opposite effects. -l locks; -d deletes the password, leaving the field empty, which means no password required rather than no login.

sudo awk -F: '$2 == "" {print $1}' /etc/shadow should return nothing.

5. pam_faillock counting nothing

The module needs a preauth entry before pam_unix and an authfail entry after it. With only the first, nothing increments the counter and no lockout ever happens, and the configuration looks complete on inspection.

faillock --user someone after three deliberate failures is the test. If the table is empty, the authfail line is missing.

6. Turning on TOTP and never being prompted

SSH public key authentication does not run the PAM auth stack, so the module is never called. AuthenticationMethods publickey,keyboard-interactive in sshd_config is what requires both, and without it you have installed a second factor that nothing invokes.

Work it through

The security team hands you a standard. Fourteen characters, one of each class, changed every 90 days, no reuse of the last ten, locked after five failures. Two hundred machines, RHEL family, humans authenticate with SSH keys and there is one legacy application account that uses a password.

Reason it out before reading on.

Split it by where each line is enforced, because that decides how many separate changes this is:

Five lines of standard, four files, two of which are generated and must not be edited directly.

Notice the trap in line one. minlen = 14 is fourteen characters only while every credit is zero or negative. A positive credit, dcredit = 1 survives in a great many inherited configuration files, lets a digit buy a character back, and the real floor drops to thirteen. Grep for the credits before you report the length as implemented, and write down whether the standard means fourteen characters or a score of fourteen, because the next auditor will read it the other way.

Third, the 90-day line is two jobs. PASS_MAX_DAYS 90 in login.defs covers accounts created from now on. Existing accounts need chage -M 90 applied individually, and doing that on all two hundred machines on the same afternoon sets every password to expire on the same day in November. Stagger it.

Fourth, ask what any of this protects. Humans log in with keys. A key-only account is not affected by password length, expiry, or history, and the only account with a real password is the legacy application, which authenticates non-interactively, so a 90-day expiry on it means the application stops working in November. That account needs chage -M -1 and a documented exception, and the exception is a better outcome than the outage.

Now change one detail. Suppose the machines were Debian rather than RHEL. Line one and two do nothing at all until libpam-pwquality is installed, and no error is produced anywhere. The module is not in the stack. The lockout line needs three hand-placed entries instead of one authselect feature. Same standard, substantially different work, which is why “we applied the policy” needs a per-family verification rather than a per-family assumption.

And one more. Suppose an auditor asks you to prove the standard is in effect. Reading /etc/security/pwquality.conf proves what the file says. pwscore proves what the machine does, feed it a thirteen-character password and a fourteen, and the pair of results is evidence rather than intent. Likewise chage -l on three real accounts beats grep PASS_MAX_DAYS /etc/login.defs in every direction.

The point worth extracting: a password policy is not one setting and it is not in one place. It is a strength check at change time, an ageing record per account, a history file, a lockout counter, and a default for accounts that do not exist yet, and each of those has its own file, its own tool, and its own way of appearing to be configured when it is not. Verify each one against a real account rather than against the file that is supposed to control it.

Try it

Optional, on a machine or container you can break.

1. grep -E '^PASS_' /etc/login.defs, then sudo useradd testy and chage -l testy. Confirm the account inherited exactly those numbers.
2. Change PASS_MAX_DAYS to 90 in login.defs and run chage -l testy again. Notice nothing changed. Then sudo chage -M 90 testy and look again.
3. sudo passwd testy, then sudo grep '^testy:' /etc/shadow and sudo passwd -S testy. Identify the algorithm from the $ prefix.
4. sudo passwd -l testy, and look at both again. Find the one character that changed. Then sudo passwd -u testy and confirm the original hash is back.
5. sudo passwd -Sa | awk '$2 == "P"'. That is the list of accounts on the machine that a password can log into. Is it as short as you expected?
6. sudo usermod -s /sbin/nologin testy, then sudo su - testy. Read the message and the exit code, and say which of authentication and shell failed.
7. sudo chage -E 2020-01-01 testy, then sudo su - testy again. Note that the error is different, and note which PAM phase produced it.
8. echo 'Passw0rd' | pwscore, then set minlen = 15 with all four credits at 0 in /etc/security/pwquality.conf and score a fourteen-character password against a fifteen.

Verification step. You have it when somebody says “the account is locked” and your next question is which of the three states they mean, and you can name the command that produced each one and the credential each one fails to stop.

Check yourself

References

• chage(1) - Linux man-pages project. Accessed 2026-08-08.
• passwd(1) - Linux man-pages project. Accessed 2026-08-08.
• shadow(5) - Linux man-pages project. Accessed 2026-08-08.
• login.defs(5) - Linux man-pages project. Accessed 2026-08-08.
• pwquality.conf(5) - Debian manpages. Accessed 2026-08-08.
• pam_pwhistory(8) - Linux man-pages project. Accessed 2026-08-08.
• pam_faillock(8) - Linux man-pages project. Accessed 2026-08-08.
• NIST SP 800-63B, Digital Identity Guidelines - National Institute of Standards and Technology. Accessed 2026-08-08.
• google-authenticator-libpam - Google. Accessed 2026-08-08.
• Pwned Passwords - Have I Been Pwned. Accessed 2026-08-08.

Captured output came from AlmaLinux 10.2 containers with shadow-utils, passwd, libpwquality, and authselect installed, using an account whose password hash was set from a fixed value so the locked and unlocked transcripts can be compared character by character. The expired-account transcript is included precisely because it does not show a refusal: su run by root short-circuits the account phase on that distribution, and showing the false negative is more useful than hiding it.

Blocks without a distribution and architecture header are illustrative. The PAM stack fragments, the sshd_config lines, the TOTP enrolment command, and the offboarding sequence are shown as they would be written rather than as captured output, because a container has no sshd, no second machine to authenticate from, and no interactive login to prompt at.