Linux password rules can be stored in different places, depending on whether they check a new password or control when an account password expires. A Linux password policy combines password-quality checks with account settings that determine when passwords expire.
I’ll show how to inspect the active PAM password stack and read an account’s aging settings alongside defaults for new accounts.
TL;DR: Linux Password Policy
Linux password policy combines password-quality checks in PAM with expiry and warning fields stored for each account.
- Read the active PAM password stack before changing its configuration.
- When libpwquality is active, inspect its main file and configuration drop-ins.
- Use chage -l username to read one account’s aging settings.
- Check distribution guidance before editing files managed by PAM tools.
What Is a Linux Password Policy?
A Linux password policy defines rules that apply when users change passwords and when account passwords reach their expiry dates.
PAM, or Pluggable Authentication Modules, lets a service call configurable authentication modules. A password stack can place pam_pwquality ahead of the module that updates the password, so the order determines when the quality check runs.
System authentication components store password hashes, while PAM modules evaluate new candidates.
| Control | Where to inspect | What it answers |
|---|---|---|
| Password quality | Active PAM password stack and pwquality settings | Which checks apply to a proposed password |
| Password history | Active PAM stack and its history module | Whether prior passwords are considered |
| Account aging | One account’s shadow aging fields | When that account’s password expires or warns |
| New-account defaults | login.defs and account-creation tools | Which aging values new accounts receive |
| Root-set password checks | Quality module options | Whether a root-set password can be rejected |
| Directory account policy | Identity provider or directory service | Where managed accounts receive password rules |
For account setup and administration, see Linux user administration. The guide to adding users to sudoers covers administrator permissions.
How to Check and Configure a Linux Password Policy
Begin by identifying the service and account you need to inspect, then choose the matching read-only command.
Choose inspection commands first because reading configuration avoids changing login behavior. The commands below show where to look.
Step 1: Read the active PAM password stack
Debian and Ubuntu commonly use common-password for the shared password stack. RHEL-family systems may use authselect to manage generated PAM files, so follow that distribution’s documented profile procedure.
grep -nE '^[[:space:]]*password' /etc/pam.d/common-password
The command lists password entries from the shared file. Locate pam_pwquality or pam_unix and read the arguments beside each module name.
Step 2: Inspect libpwquality settings
When libpwquality is active, system defaults can be set in pwquality.conf, with drop-ins under pwquality.conf.d taking precedence when they override a value.
Use the option names in the search to identify configured values and check the installed module manual before changing them.
grep -nE '^[[:space:]]*(minlen|difok|dcredit|ucredit|lcredit|ocredit|enforcing|retry)[[:space:]]*=' /etc/security/pwquality.conf /etc/security/pwquality.conf.d/*.conf
| Option | Effect to verify | Decision question |
|---|---|---|
| minlen | Minimum candidate length | What length meets the system’s approved policy? |
| difok | Difference from the previous password | Should a new candidate differ by a specified amount? |
| dcredit | Digit requirement or length contribution | Does the chosen sign require digits or affect length? |
| ucredit, lcredit, ocredit | Uppercase, lowercase, and other-character credits | Which classes, if any, are required by local policy? |
| enforcing | Rejection or warning behavior | Does the active module reject failed checks? |
| retry | How many password attempts the module allows | What limit does the installed module support? |
The shell expands the *.conf wildcard before grep runs. If no drop-in matches, grep may report a missing literal path. Read that message alongside the main file before deciding whether drop-ins exist.
Step 3: Choose quality values for the system
Choose values for the affected account population and applicable policy, then use the configuration below to compare length and password-change controls.
minlen = 14
difok = 3
ucredit = 0
dcredit = 0
lcredit = 0
ocredit = 0
enforcing = 1
retry = 3
This set uses length and difference values without requiring character classes through negative credits. Confirm the installed module’s behavior with an approved account before wider use.
During an approved test, observe whether a candidate that fails the rule produces a warning or a rejected change. Check a permitted candidate separately, and keep the test account outside critical workflows.
Record the module version and active PAM profile alongside any approved values so later comparisons use the same change path.
| Before adopting a value | Reason to check |
|---|---|
| Confirm the governing policy | Local rules may come from an organization or service owner |
| Review affected services | Each password-change path may load a different PAM stack |
| Check the installed manual | The manual documents option syntax and module-specific behavior |
| Test an approved account | A controlled test reveals whether the expected rejection occurs |
| Plan a rollback | A rejected change should not leave users without a recovery route |
Step 4: Read aging settings for an account
chage -l username displays aging values stored for a named local account.
chage -l username
Replace username with the account name, and keep account details private when sharing diagnostic output.
| Field in chage output | Meaning |
|---|---|
| Last password change | Date of the last password update |
| Minimum days | Shortest interval before another change |
| Maximum days | Interval before the password expires |
| Warning days | Notice period before expiry |
| Password inactive | Grace period after expiry before the password is disabled |
| Account expires | Date the account itself becomes unavailable |
Before an aging change, verify the details in this checklist.
| Check | Why it matters |
|---|---|
| Account name and source | Apply the change to the intended local or directory account |
| Approved minimum and maximum intervals | Set dates that match the organization’s rule |
| Warning period | Give users time to change an expiring password |
| Recovery path | Restore access if a chosen date blocks a user |
For a planned change, check the local manual for -M and -W, then verify the resulting record with chage -l.
Step 5: Review defaults for new accounts
Inspect password-aging defaults in login.defs. New accounts can inherit these values, while existing accounts keep their recorded settings until an administrator changes them.
grep -nE '^[[:space:]]*PASS_(MAX_DAYS|MIN_DAYS|WARN_AGE)' /etc/login.defs
| Default to compare | Account value | Why compare |
|---|---|---|
| PASS_MAX_DAYS | Maximum days | Find differences in expiry intervals |
| PASS_MIN_DAYS | Minimum days | Check how soon the user may change a password |
| PASS_WARN_AGE | Warning days | Confirm that the account receives advance notice |
| Directory policy | Directory account settings | Explain values supplied outside local files |
Review one representative account from each managed account class before applying the approved policy.
Account-creation tools can also set values when a new user is created. Compare their documented defaults with login.defs before changing a creation workflow.
See SSH key-based login for remote access and the guide to encrypting files or directories for file protection.
Common Errors and What to Check Next
Use the table to choose a focused follow-up because a warning and a missing setting call for different evidence.
| Symptom | Likely cause | Next check |
|---|---|---|
| A warning appears, but the password change succeeds | The module may warn instead of rejecting, or root-specific settings may apply | Read enforcement and root options in the active PAM stack and module manual |
| Changing pwquality.conf has no effect | The service may use another stack, skip the module, or pass overriding arguments | Inspect the service stack and its effective module arguments |
| New and existing accounts have different expiry values | New-account defaults and stored aging records serve different purposes | Compare login.defs with chage -l for an existing account |
| PAM edits disappear after a system update | A distribution tool may regenerate the configuration | Check the active profile and supported management procedure |
| A root-set password bypasses a quality failure | Root-specific enforcement may be disabled | Check enforce_for_root in the module manual |
| Password history is not checked | The history module may be absent from the active stack | Check whether pam_pwhistory is installed and configured |
| Local account details conflict with central policy | A directory or identity provider may own the account rules | Inspect the account source and its policy interface |
| The shared PAM file is missing | The distribution uses a different file layout | Follow that system’s service-specific documentation |
| An empty pwquality search is returned | The values may live in another drop-in or module argument | Review the complete configuration source in documented order |
| One application rejects a password while another accepts it | The applications can load different service stacks | Compare the PAM files used by both password-change paths |
| A user receives no warning before expiry | The aging record or notification path may omit a warning | Check warning days and the user-facing notice mechanism |
| A directory user cannot change a password locally | The directory may own password changes for that account | Use the provider’s supported policy and recovery path |
| Policy edge case | What to verify |
|---|---|
| Root-set password checks | The Ubuntu pam_pwquality manual documents enforce_for_root for rejecting failed checks. Root supplies no old password, so old-versus-new checks cannot run in that path. |
| Password history | Linux-PAM provides pam_pwhistory, but integration varies by distribution. Check the installed module manual for accepted options and placement before editing the service stack. |
NIST’s fourth revision of Special Publication 800-63B advises covered verifiers against composition requirements and discusses blocklists and throttling. Its guidance addresses digital identity services.
A blocklist rejects candidate passwords known to be weak or exposed. Throttling slows repeated authentication attempts. A verifier can apply these checks alongside its other approved controls.
Set an expiry schedule when an applicable policy calls for it. Verify warning delivery and account recovery before enabling the schedule.
For host-level controls, read about Linux firewalls, SELinux and AppArmor.
Conclusion: Keep Policy Layers Separate
Use the distribution-supported mechanism for an approved change, then verify its effect with a controlled account test. Record the setting and the accounts covered by the policy.
For related account-security tasks, see password-protecting files.
FAQ
These answers point to the configuration layer that matches each question.
How do I check the password policy in Linux?
Inspect the active PAM password stack and its quality-module options, then run chage -l username to read one account’s aging settings. A local file may omit directory-managed rules.
Does changing login.defs update existing accounts?
login.defs supplies defaults for newly created accounts. Inspect existing account aging separately with chage -l.
What does dcredit=-1 mean in pwquality?
A negative dcredit value requires a minimum number of digits. A non-negative value contributes to the length calculation.
Does Linux require uppercase letters and symbols in passwords?
Linux has no single universal rule. PAM modules can enforce configured character classes, while the active stack and local policy determine what applies.
Why does a weak password warning still allow a change?
The active module may only warn, may be absent from the service stack, or may use root-specific behavior. Check the effective PAM options.