Table of Contents
Understanding Authentication Policies on Linux
In the context of system security, an authentication policy defines how users prove their identity, under what conditions they are allowed to log in, and how those identities are managed and enforced across different services.
On Linux, authentication is mostly implemented through:
- Local files (like
/etc/passwd,/etc/shadow) - Pluggable Authentication Modules (PAM)
- Optional central identity services (LDAP, Active Directory, etc.)
This chapter focuses on configuring and enforcing policies around authentication, not on basic user account concepts or SSH details (covered elsewhere).
Core Building Blocks of Authentication
Local Account Databases
On a typical standalone Linux system, authentication uses:
/etc/passwd– maps usernames to UIDs and basic info
(password field is usuallyxto indicate the real hash is in/etc/shadow)/etc/shadow– stores hashed passwords and password policy fields:
Each line in /etc/shadow looks like:
username:password_hash:lastchg:min:max:warn:inactive:expire:reserved
Key fields for policy:
min– minimum days between password changesmax– maximum days a password is validwarn– days before expiry that user gets warningsinactive– days after expiration before account is disabledexpire– absolute date (in days since 1970-01-01) when account expires
You typically modify these via tools instead of editing directly.
PAM (Pluggable Authentication Modules) Overview (Policy Angle)
PAM is the main framework that enforces authentication policies for different services (login, SSH, sudo, graphical logins, etc.).
- Config files live in
/etc/pam.d/(per-service) and sometimes/etc/pam.conf - Each service file (e.g.,
/etc/pam.d/sshd,/etc/pam.d/sudo) includes rules like:
auth required pam_unix.so
account required pam_unix.so
password requisite pam_pwquality.so retry=3
session required pam_limits.soPolicy tuning is usually done by:
- Adding/removing/changing
pam_*modules - Adjusting module options (e.g., password complexity, retry limits, lockouts)
We’ll focus on what kinds of policies you can implement via PAM, not the full PAM architecture.
Password Policy Controls
Global Password Aging with `login.defs`
/etc/login.defs controls default password policies for new accounts and some global login behavior.
Common directives:
PASS_MAX_DAYS– maximum days between password changePASS_MIN_DAYS– minimum days between changesPASS_WARN_AGE– days before expiration to start warning
Example:
PASS_MAX_DAYS 90
PASS_MIN_DAYS 1
PASS_WARN_AGE 7This means:
- Users must change passwords every 90 days
- Cannot change password more than once per day
- Get warnings starting 7 days before expiration
These defaults apply when new users are created (e.g., with useradd), but do not automatically retroactively change existing accounts.
Per-User Password Aging with `chage`
chage configures password aging for individual users.
Common usages:
- Show a user’s password aging info:
sudo chage -l alice- Set maximum days before expiry:
sudo chage -M 90 alice- Set minimum days:
sudo chage -m 1 alice- Set warning period:
sudo chage -W 7 alice- Force password change on next login:
sudo chage -d 0 alicePolicy approach:
- Use
login.defsto define organization-wide defaults - Use
chagefor exceptions or manual corrections
Password Complexity (Quality) Policies
Password strength rules are typically enforced by PAM modules such as:
pam_pwquality.so(common on many distros)- Older systems might use
pam_cracklib.so
Config locations vary by distro, but common places are:
/etc/pam.d/common-password(Debian/Ubuntu w/ PAM includes)- Directly in
/etc/pam.d/system-author similar (RHEL/Fedora)
An example pam_pwquality line:
password requisite pam_pwquality.so retry=3 minlen=12 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1Key options (simplified):
minlen=12– minimum lengthucredit=-1– require at least 1 uppercase letterlcredit=-1– require at least 1 lowercase letterdcredit=-1– require at least 1 digitocredit=-1– require at least 1 “other” (symbol)
Other commonly used options:
difok=N– require at least $N$ characters to be different from the old passwordreject_username– reject passwords containing the usernamemaxrepeat=N– limit consecutive repeated charactersusercheck– reject passwords based on user info
Security vs usability:
- Extremely strict rules may cause users to write passwords down or reuse patterns.
- A practical approach is decent complexity + longer length (12–16) and encouraging passphrases.
Password Locking and Disabling Accounts
You can lock accounts to prevent logins without deleting them.
Tools:
passwd -l USER– lock password-based logins by prepending!to the hash in/etc/shadowpasswd -u USER– unlock
Examples:
- Lock a user account:
sudo passwd -l alice- Unlock it:
sudo passwd -u aliceFor system/service accounts that should never be used interactively:
- Use a disabled shell like
/usr/sbin/nologinor/bin/false - Or set a
!or*in the password field
Account Lockout and Login Attempt Limits
To limit brute-force attacks against passwords, you can enforce lockout policies via PAM.
Two commonly used modules (distribution-dependent):
pam_faillock.sopam_tally2.so(older, deprecated on some systems)
Example Using `pam_faillock` (RHEL/Fedora, Many Modern Systems)
Configuration may be in files like:
/etc/pam.d/system-auth/etc/pam.d/password-auth
Simplified example lines (actual distro syntax may differ):
auth required pam_faillock.so preauth silent audit deny=5 unlock_time=900
auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail audit
account required pam_faillock.soKey options:
deny=5– lock account after 5 failed attemptsunlock_time=900– unlock after 900 seconds (15 minutes)fail_interval=300(if used) – count failures within 300 seconds (5 minutes)
Policy points:
- Use temporary lockouts for normal users (e.g., 10–15 minutes)
- Be more careful on remote access services (like SSH) to avoid denying legitimate users too easily
- Combine with network-level defenses (firewall, SSH protections) for better results
Session and Login Restrictions
Authentication policies often include where and when users can log in.
Limiting Logins by Terminal (`/etc/security/access.conf` and `pam_access`)
pam_access.so uses /etc/security/access.conf to restrict logins based on:
- Username
- Group
- Local or remote host
PAM line (found in some /etc/pam.d/* files):
account required pam_access.so
/etc/security/access.conf rules look like:
# permission : users/groups : origins
-:root:ALL EXCEPT LOCAL
-:ALL EXCEPT wheel:192.168.1.0/24
+ : ALL : LOCALInterpretation (simplified):
-:root:ALL EXCEPT LOCAL– root can only log in on local console-:ALL EXCEPT wheel:192.168.1.0/24– onlywheelgroup can log in from that network+ : ALL : LOCAL– allow all local logins
Policy use cases:
- Restrict root login to local terminals
- Limit remote logins to admin groups
- Block specific users or groups from certain login methods
Controlling Maximum Simultaneous Logins (`/etc/security/limits.conf`)
pam_limits.so reads /etc/security/limits.conf to set resource limits and sometimes max logins per user.
Example entries:
@students hard maxlogins 1
@teachers hard maxlogins 5This can prevent account sharing or overuse.
Note: The effect can depend on how sessions are counted (virtual terminals, SSH sessions, graphical logins); behavior may vary between setups.
Time-Based Access Restrictions (Optional Module: `pam_time`)
pam_time.so can limit access based on time of day.
PAM line (in account section):
account required pam_time.so
Rules in /etc/security/time.conf, e.g.:
# services;ttys;users;times
login tty* !root MoFr0800-1800
Very roughly: prevent non-root users from logging in with login outside Monday–Friday 08:00–18:00.
This module is less commonly used but can be relevant in tightly controlled environments.
Centralized Authentication and Policies (Overview-Level)
Beyond local accounts, many organizations want central identity management so that:
- Users and groups are defined centrally (LDAP, Active Directory, FreeIPA, etc.)
- Policies (like password rules, lockouts) are set once and apply across multiple servers
Common Linux tools/approaches:
sssd– System Security Services Daemon; integrates with LDAP/AD/FreeIPA and caches credentialsnsswitch.conf– controls where the system looks up user and group info (files, LDAP, etc.)- PAM modules for LDAP, Kerberos, etc.
From an authentication policy perspective:
- You might enforce password rules and account lockouts on the identity provider, not per-machine
- Local PAM configs still matter for how auth is requested and combined (e.g., local + domain accounts)
For this course stage, know that:
- Local Linux policies can coexist with centralized policies
- In enterprise environments, local
/etc/passwdusers are often only admins or service accounts; normal users come from the central directory
Multi-Factor Authentication (MFA) Basics on Linux
MFA strengthens authentication policies by requiring something more than just a password, typically:
- Time-based one-time passwords (TOTP; Google Authenticator-style codes)
- Hardware keys (U2F/FIDO2, smartcards)
- SMS/Email codes (less secure, often avoided on servers)
On Linux, MFA is usually implemented through additional PAM modules, for example:
pam_google_authenticator.sofor TOTP codespam_u2f.soor similar for hardware keys
Typical high-level steps for TOTP-based MFA (example):
- Install a TOTP PAM module (
libpam-google-authenticatoror distro equivalent) - Add a line to relevant PAM services, e.g.
/etc/pam.d/sshd:
auth required pam_google_authenticator.so nullok- Configure SSH or login service to require both password and one-time code
- Each user runs a setup tool (like
google-authenticator) to generate a secret and QR code, then stores it in an app (e.g., on a phone)
Policy considerations:
- Decide which accounts require MFA (admins should, at minimum)
- Consider fallback/backup methods (lost phone, hardware key)
- Document procedures clearly for users
Practical Policy Design Considerations
When designing authentication policies on Linux systems, aim for a balance of security and usability:
- Passwords
- Require reasonable complexity and length
- Avoid overly frequent forced changes (e.g., every 30 days) unless regulations require them
- Lockouts
- Implement lockouts or delays after several failed attempts
- Avoid permanent lockouts that require manual intervention for small mistakes
- Least privilege & access scope
- Restrict root remote logins
- Use
sudowith policies instead of sharing root passwords - Limit which users can log in via SSH or console
- Centralization (when possible)
- Use directory services for consistent policies across many machines
- MFA for high-value accounts
- Apply MFA at least for administrative and remote access
Document your policies and test changes on a non-critical system before rolling them out widely, especially when editing PAM configs; misconfiguration can lock you out.
Summary
Authentication policies on Linux are implemented using:
- Local account settings (
/etc/shadow,chage,login.defs) - PAM modules and configuration files (
/etc/pam.d/,/etc/security/) - Optional centralized identity systems (LDAP/AD/SSSD)
- Enhancements like MFA and account lockouts
Understanding where to set which rule (aging, complexity, lockouts, restrictions, MFA) is the key to building a secure, manageable authentication policy for your Linux systems.