Lockout, password quality and password aging

The idea

Three controls shape how an account may be used, and each has its own file and its own place in the PAM stack:

Control	Question it answers	Configured in	Enforced by
Lockout	Too many wrong passwords?	/etc/security/faillock.conf	pam_faillock (auth and account)
Quality	Is this new password strong enough?	/etc/security/pwquality.conf	pam_pwquality (password)
Aging and expiry	Is it time to change the password? Is the account still valid?	/etc/shadow fields (set with chage), defaults in /etc/login.defs and /etc/default/useradd	pam_unix (account)

They are different checks, so a locked-out user, an expired password and an expired account give different symptoms and need different fixes.

Lockout with pam_faillock

pam_faillock counts failed authentications per user, stored under /var/run/faillock/, and refuses logins once the count passes a limit. RHEL needs it enabled through authselect (with-faillock), then you tune it in /etc/security/faillock.conf:

deny = 3
fail_interval = 900
unlock_time = 600
even_deny_root
root_unlock_time = 60

Option	Meaning
deny	Lock after this many consecutive failures
fail_interval	Failures count only within this window (seconds)
unlock_time	Seconds until the lock clears by itself (0 = never; admin must reset)
even_deny_root	Apply the policy to root as well (default: root is exempt)
root_unlock_time	Unlock time for root, if different
audit, silent	Log or hide the “account locked” message
dir	Where the records are kept

sudo faillock --user labuser1            # list failures
sudo faillock --user labuser1 --reset    # clear them
sudo faillock                            # everyone

labuser1:
When                Type  Source                                           Valid
2026-11-04 12:51:03 TTY   /dev/pts/2                                           V
2026-11-04 12:51:07 TTY   /dev/pts/2                                           V
2026-11-04 12:51:11 TTY   /dev/pts/2                                           V

(Representative output.) Three valid (V) failures with deny = 3 means the user is locked right now. Entries flip to I (invalid) once they age out of the interval.

Password quality with pam_pwquality

When a user changes a password with passwd, pam_pwquality rates it. Settings in /etc/security/pwquality.conf:

Option	Meaning
minlen	Minimum length (a credit system counts character classes toward this, so set it to the real minimum you want)
minclass	Minimum number of character classes (lower, upper, digit, other)
dcredit, ucredit, lcredit, ocredit	Positive = credit, negative (-1) = require at least that many of that class
maxrepeat, maxclassrepeat	Limit identical characters or class runs in a row
dictcheck, usercheck	Reject dictionary words or the user name
retry	How many times the user may try in one passwd run
enforce_for_root	Apply the rules when root sets a password (root may otherwise override with a warning)

Test the rules without changing a password:

echo 'password1' | pwscore
echo 'Tr0ub4dor&3x-Quartz' | pwscore
pwmake 128           # generate a random password with 128 bits of entropy

Password quality check failed:
 The password fails the dictionary check - it is based on a dictionary word
69

(Representative output.) pwscore prints the reason for a rejection or a score from 0 to 100. Quality is checked on change; it does not examine passwords already set. And chpasswd/useradd -p set the hash directly: whether they pass through the quality check depends on the PAM configuration, so test the real passwd path.

Aging and expiry

An account has two independent time limits stored in /etc/shadow:

• Password aging: min days between changes, max days before a change is forced, warning period, and an inactivity grace period after expiry before the account locks.
• Account expiry: a date after which the account cannot be used at all.

sudo chage -l labuser1
sudo chage -M 90 -m 7 -W 14 -I 5 labuser1       # max, min, warn, inactive days
sudo chage -E 2027-06-30 labuser1               # account expires on this date (-1 removes it)
sudo chage -d 0 labuser1                        # force a change at the next login

Real output from a test account, before and after chage -M 90 -m 7 -W 14 -I 5:

Last password change					: Nov 04, 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
---
Last password change					: Nov 04, 2026
Password expires					: Feb 02, 2027
Password inactive					: Feb 07, 2027
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

The expiry dates are computed: 90 days after the last change gives Feb 02, 2027, and 5 inactive days after that Feb 07, 2027. Between those two dates the user can still log in but must change the password; after the second date the account is locked.

Where defaults for new accounts come from:

Setting	File	Affects
PASS_MAX_DAYS, PASS_MIN_DAYS, PASS_WARN_AGE	/etc/login.defs	Accounts created afterwards (and changes through passwd)
INACTIVE (inactivity days)	/etc/default/useradd (set with useradd -D -f DAYS)	New accounts
UMASK, UID/GID ranges	/etc/login.defs	New accounts
Anything on an existing account	chage -l USER / /etc/shadow	Only that account

Real output of the defaults on the test machine (the values shown are the unmodified defaults):

PASS_MAX_DAYS	99999
PASS_MIN_DAYS	0
PASS_WARN_AGE	7

Locked, expired or disabled?

Real output of a test account through these states:

passwd -S labuser1                # usable password
usermod -L labuser1; passwd -S labuser1
usermod -U labuser1
chage -E 2020-01-01 labuser1; chage -l labuser1 | sed -n 4p; passwd -S labuser1

labuser1 P 2026-11-04 7 90 14 5
labuser1 L 2026-11-04 7 90 14 5
Account expires						: Jan 01, 2020
labuser1 P 2026-11-04 7 90 14 5

passwd -S fields: name, status (P usable, L locked, NP no password), last change, min, max, warn, inactive. After usermod -L the status is L (the hash in /etc/shadow now starts with !). After setting a past expiry date the status is still P: the password is fine, the account is expired. The user cannot log in, but the reason is in chage -l, not in passwd -S.

State	Look at	Release
Password locked	passwd -S → L; ! in shadow	usermod -U (or set a new password)
Faillock	faillock --user	faillock --user U --reset
Password expired	chage -l password expires in the past	New password, or chage -d / -M
Inactive too long	chage -l Password inactive passed	Admin must chage -I -1 and set a new password
Account expired	chage -l Account expires	chage -E -1
No shell	getent passwd U shows /sbin/nologin	usermod -s /bin/bash U

Going further

Why root can set weak passwords. pam_pwquality warns when root sets a weak password but accepts it unless enforce_for_root is set. Test policies as an ordinary user. Beyond the exam: pam_pwhistory stops reuse of recent passwords (remember = 5), pam_faillock records can be audited with ausearch -m USER_AUTH, and for centrally managed accounts (IdM, Active Directory) the equivalent policies live on the server side, not in these files.