Linux PAM Configuration Demystified: Secure Authentication for Enterprise Systems

For Linux administrators managing enterprise environments, authentication and authorization are among the most critical responsibilities. One of the most powerful yet often misunderstood frameworks underpinning Linux authentication is PAM (Pluggable Authentication Modules).

In this in-depth guide, we’ll explore:

What PAM is and how it works

Core PAM components and configuration files

Commonly used PAM modules and their use cases

The role of authselect on RHEL 8+

Security best practices

Real-world examples to help you master PAM

What Is PAM in Linux?

PAM (Pluggable Authentication Modules) is a flexible authentication framework that decouples authentication logic from individual applications. Instead of each application implementing its own password checks, they all plug into the central PAM stack, which calls various PAM modules to handle tasks like:

Password verification

Account restrictions

Session setup

Resource limits

This modular architecture allows you to add, remove, or reconfigure authentication methods without changing application code.

Real-World Example

Consider passwd and login—two common commands. Running ldd on these binaries reveals their dependency on libpam.so.0, which provides PAM functionality:

ldd $(which passwd) 
linux-vdso.so.1 (0x00007fff1a5d2000) 
libuser.so.1 => /lib64/libuser.so.1 (0x00007f7addf1c000) 
libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007f7addcc9000) 
libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007f7add9af000) 
libpopt.so.0 => /lib64/libpopt.so.0 (0x00007f7add7a2000) 
libpam.so.0 => /lib64/libpam.so.0 (0x00007f7add592000) 
libpam_misc.so.0 => /lib64/libpam_misc.so.0 (0x00007f7add38e000) 
libaudit.so.1 => /lib64/libaudit.so.1 (0x00007f7add15d000)
-----
ldd $(which login)
libpam.so.0 => /lib64/libpam.so.0
libpam_misc.so.0 => /lib64/libpam_misc.so.0
------

This means both commands rely on PAM to authenticate users.

PAM Configuration Files: /etc/pam.d

The core configuration for PAM resides in /etc/pam.d. Each file in this directory corresponds to a PAM-aware application (like login, sshd, passwd, sudo, su etc.) and defines which PAM modules should be called during authentication.

Example directory listing:

ls /etc/pam.d
login  passwd  sshd  system-auth  password-auth  su  sudo  ...

Each file contains PAM stack entries in the format:

type control_flag module module_arguments

Where:

type: auth, account, password, session

control_flag: Determines behavior if module succeeds/fails (required, sufficient, requisite, etc.)

module: The PAM module (e.g., pam_unix.so, pam_sss.so)

arguments: Optional module-specific flags (e.g., try_first_pass)

PAM Stack Types

PAM stacks are divided into four management groups:

A Closer Look: /etc/pam.d/login

Here’s an example login file:

auth       substack     system-auth
auth       include      postlogin
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
session    required     pam_selinux.so close
session    required     pam_loginuid.so
session    optional     pam_console.so
session    required     pam_selinux.so open
session    required     pam_namespace.so
session    optional     pam_keyinit.so force revoke
session    include      system-auth
session    include      postlogin
session    sufficient   pam_lsass.so

• **substack/include**: Pull in configuration from other files like system-auth (common stack) and postlogin.
• **pam_nologin.so**: Blocks logins if /etc/nologin exists (e.g. during maintenance).

This modularity allows global policies (like password rules) to be applied system-wide via system-auth while still customizing individual services like login or sshd.

PAM on RHEL 8+: Authselect

In RHEL 8 and newer, manual editing of PAM config files is discouraged. Instead, use **authselect** to manage PAM profiles safely.

A few sample commands:

authselect current
# Shows current profile
authselect list-features minimal
# Lists available optional features
authselect show minimal
# Shows full profile description
authselect select minimal with-pwhistory with-mkhomedir
# Select profile with specific features
authselect enable-feature with-faillock
# Enable feature on current profile

This tool ensures consistent and supported configurations. Profiles live in /etc/authselect/ and generate the actual PAM stack in /etc/pam.d.

Exploring /etc/pam.d/system-auth

system-auth is a central stack included by other PAM configs, containing the main policies:

auth        required        pam_env.so
auth        required        pam_faildelay.so delay=2000000
auth        sufficient      pam_lsass.so smartcard_prompt try_first_pass
auth        sufficient      pam_unix.so nullok
auth        sufficient      pam_sss.so forward_pass
auth        required        pam_deny.so
account     required         pam_unix.so
account     sufficient       pam_localuser.so
account     required         pam_permit.so
password    requisite         pam_pwquality.so local_users_only retry=3
password    requisite         pam_pwhistory.so remember=5 use_authtok
password    sufficient        pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required           pam_deny.so
session     required           pam_limits.so
session     required           pam_unix.so

Let’s break down the important modules used here.

Deep Dive: Key PAM Modules

Here are the most critical PAM modules you’ll encounter as a Linux admin:

pam_env.so — Environment Setup

• Sets environment variables for user sessions
• Reads from /etc/security/pam_env.conf and /etc/environment
• Typically used early in the stack

Example:

auth required pam_env.so

pam_faildelay.so — Anti-Bruteforce Delay

• Adds delay between failed logins (microseconds)
• Thwarts brute-force attacks

Example:

auth required pam_faildelay.so delay=2000000  # 2-second delay

pam_usertype.so — User Classification

• Checks if user is regular, system, etc.
• Useful for applying different policies to system vs regular users

Example:

auth [default=2 ignore=ignore success=ok] pam_usertype.so isregular

pam_lsass.so — Active Directory Authentication

• Provided by BeyondTrust/PowerBroker (Likewise) LSASS
• Enables Linux authentication via Active Directory
• Supports smartcards, SSO, password sync, and group policies

Common arguments:

• smartcard_prompt
• try_first_pass
• use_authtok
• unknown_ok

Example:

auth sufficient pam_lsass.so smartcard_prompt try_first_pass
account required pam_lsass.so unknown_ok
password sufficient pam_lsass.so try_first_pass use_authtok

**unknown_ok** lets the stack continue if a user isn’t found in AD — useful in hybrid (local + domain) environments.

pam_localuser.so vs pam_unix.so

Feature pam_localuser.so pam_unix.so Purpose Check if user exists locally Full Unix authentication Checks passwords? No Yes Manages sessions? No Yes Common Use Pre-check before other modules Main local authentication Scope /etc/passwd only /etc/passwd + /etc/shadow Typical Placement Early in auth stack Throughout all stack types

Example:

auth [default=1 ignore=ignore success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok

pam_unix.so — Core Local Authentication

• Handles password verification, account validity, session creation, password changes
• Supports SHA512 hashing, shadow passwords, and try_first_pass

Example:

auth sufficient pam_unix.so nullok try_first_pass
account required pam_unix.so
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
session required pam_unix.so

pam_sss.so — SSSD Authentication

• Integrates with SSSD (System Security Services Daemon)
• Used for LDAP/AD/Kerberos identities managed via SSSD

Example:

auth sufficient pam_sss.so forward_pass
password sufficient pam_sss.so use_authtok

pam_pwquality.so & pam_pwhistory.so

• Enforce password complexity (pam_pwquality.so)
• Prevent reuse of old passwords (pam_pwhistory.so)

Example:

password requisite pam_pwquality.so retry=3
password requisite pam_pwhistory.so remember=5 use_authtok

pam_limits.so — Resource Limits

• Enforces per-user limits from /etc/security/limits.conf

Example:

session required pam_limits.so

pam_deny.so and pam_permit.so

• pam_deny.so: Always fails (security fallback)
• pam_permit.so: Always succeeds (for testing only — dangerous!)

Example:

auth required pam_deny.so
account required pam_permit.so

Understanding try_first_pass vs use_first_pass vs use_authtok

These arguments control how PAM modules handle passwords:

Option Behavior try_first_pass Try existing password, prompt if none use_first_pass Must use existing password, fail if none use_authtok Used during password changes — reuse the new password entered earlier

Rule of thumb: Use try_first_pass for authentication modules and use_authtok for password modules.

PAM Module Location and Documentation

All PAM modules live under /usr/lib64/security/ on RHEL systems:

ls /usr/lib64/security/
pam_unix.so  pam_lsass.so  pam_sss.so  pam_limits.so  pam_deny.so  ...

Each module has its own man page:

man pam_securetty
man pam_unix
man pam_deny

Reading these is crucial to safely customizing PAM.

Best Practices for Linux Admins

To wrap up, here are battle-tested PAM best practices for experienced admins:

1. Use authselect on RHEL 8+

• Never edit system-auth or password-auth manually
• Create a custom profile if you need to modify defaults

2. Order Matters

• Place environment and user-type modules first
• Put pam_deny.so last as a secure fallback
• Use sufficient for optional modules and required for must-pass ones

3. Understand Control Flags

• required: must pass, but continue stack
• requisite: must pass, stop on failure
• sufficient: success ends stack if no prior failures
• optional: used only if it’s the only module of that type

4. Monitor Authentication Logs

• Check /var/log/secure ,journalctl -u sshd or /var/log/audit logs to debug PAM issues
• Use pam_tally2 or faillock for failed login tracking

Final Thoughts

PAM is one of the most powerful and flexible security frameworks in Linux. Understanding how modules like pam_unix.so, pam_lsass.so, pam_localuser.so, and pam_deny.so work together allows you to:

• Build hybrid local + domain authentication stacks
• Enforce strong password policies
• Apply per-user access controls and limits
• Securely manage session environments

Further Reading

• man pam(8)
• man pam_unix(8)
• man pam_lsass(8)
• man authselect(8)
• Red Hat PAM Documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/