0 - kevwells.com
by

Pluggable Authentication Modules (PAM): Controlling Access in Linux

Pluggable Authentication Modules (PAM) form the backbone of authentication and access control on most modern Linux systems. In my work, PAM is often overlooked or misunderstood. Administrators know it exists but rarely configure it beyond the defaults. That leaves opportunities for weak passwords, mismanaged access, and non-compliance.

This article sets out how PAM works, why it matters, and how to configure it effectively for security.

1. What PAM Is

PAM is a framework that lets administrators plug in authentication methods without modifying applications directly. When a service such as sshd or login needs authentication, it calls PAM. PAM then evaluates configured modules to allow or deny access.

Key points:

  • Configuration files live in /etc/pam.d/ or /etc/pam.conf.

  • Each file specifies which modules apply to a particular service.

  • Modules can stack, meaning multiple checks occur for a single login.

2. PAM Control Types

PAM rules are evaluated in sequence. Each rule has a control type:

  • auth – authenticates the user (e.g. password check).

  • account – verifies account restrictions (e.g. expiry date).

  • password – manages password updates.

  • session – defines actions at login or logout.

In practice, this means you can enforce layered policies such as password complexity, account expiration, and session logging.

3. Common PAM Modules

The following modules are widely deployed:

  • pam_unix – standard Linux password authentication.

  • pam_tally2 or pam_faillock – tracks failed login attempts, supports lockouts.

  • pam_pwquality – enforces password strength.

  • pam_google_authenticator – adds TOTP multi-factor authentication.

  • pam_time – restricts login times by account.

When I review systems, I often find only pam_unix in use.  That leaves no protection against brute force, weak passwords, or out-of-hours access.

4. Password Complexity with PAM

To enforce strong passwords, configure pam_pwquality.

Example in /etc/pam.d/common-password (Debian/Ubuntu):

 
password requisite pam_pwquality.so retry=3 minlen=12 ucredit=-1 lcredit=-1 dcredit=-1 ocredit=-1

This enforces a 12-character minimum with at least one upper, one lower, one digit, and one other symbol.

In my experience, compliance audits often highlight weak password policies. PAM makes it straightforward to enforce stronger requirements.

5. Account Lockouts

Account lockouts reduce brute-force attempts. Configure pam_faillock (RHEL) or pam_tally2 (older distros).

Example with pam_faillock:

 
auth required pam_faillock.so preauth silent deny=5 unlock_time=600
auth [success=1 default=bad] pam_unix.so
auth [default=die] pam_faillock.so authfail
account required pam_faillock.so

This locks an account after 5 failed logins for 10 minutes.

In IT security work, you often come across systems where brute force attempts are logged but not actively blocked. PAM provides an immediate mitigation for this!

6. Multi-Factor Authentication (MFA)

For sensitive systems, add a second factor to PAM.

  • Install libpam-google-authenticator.

  • Add to /etc/pam.d/sshd:

     
    auth required pam_google_authenticator.so nullok

This requires a TOTP code in addition to a password or key.

I’ve implemented this in environments where SSH was a high-value target.  It provides a strong assurance against credential theft.

7. Restricting Login Times

pam_time lets you restrict access to certain hours or days.

Example in /etc/security/time.conf:

 
*;*;adminuser;!Wd0000-0800

This denies adminuser access outside working hours.

This is useful for contractor accounts or systems where support should only occur during defined times.

8. Session Controls

PAM can run actions at session start and end. For example:

  • Mounting home directories.

  • Setting resource limits with pam_limits.

  • Logging session data.

Example in /etc/security/limits.conf:

 
@admins hard nproc 100

This limits the number of processes for users in the admins group.

9. PAM Best Practices

From my experience, the following principles are essential:

  • Always test carefully: PAM misconfiguration can lock you out of a system. Use a non-production machine or ensure a root session stays open during changes.

  • Document your rules: Auditors often ask to see how password policies and lockouts are enforced.

  • Keep it minimal: Only load modules you need. More modules mean more complexity and possible conflicts.

  • Centralise where possible: For large estates, integrate with LDAP or Active Directory via PAM modules for consistent policy enforcement.

10. PAM and Compliance

Compliance frameworks often map directly to PAM settings:

  • CIS benchmarks: enforce password length and complexity via pam_pwquality.

  • ISO27001: enforce account lockouts and session management.

  • GDPR: demonstrate appropriate access controls.

Being able to show PAM configurations that enforce these policies provides strong evidence during audits.

Conclusion

PAM is one of the most powerful but underused security tools in Linux. When configured properly, it enforces password strength, prevents brute force attacks, enables MFA, and aligns systems with compliance requirements.

In my view ignoring PAM is a mistake. Administrators who rely only on defaults leave a significant gap in their security posture.  If you make careful, tested adjustments, PAM can deliver strong, auditable access control across your Linux environment.  

Security gaps in Linux and cloud systems risk downtime, data compromise, lost business — and compliance failures.

With 20+ years’ experience and active UK Security Check (SC) clearance, I harden Linux and cloud platforms for government, corporate, and academic sectors — ensuring secure, compliant, and resilient infrastructure.

Contact for Contract Assignments

No related posts.