Table of Contents
Understanding Authentication Policies on Linux
Authentication policies define how users prove their identity to a Linux system and under what conditions access is granted or denied. In this chapter you will see how Linux structures these rules, where they are configured, and which practical controls you can apply as an administrator. General user and group administration is covered elsewhere, so the focus here is on how logins are checked and controlled.
The Role of PAM in Linux Authentication
On most modern Linux systems, Pluggable Authentication Modules, usually called PAM, provide the central framework for authentication. Instead of each application implementing its own password and access logic, programs such as login, sshd, sudo, su, graphical display managers, and screen lockers all call into PAM.
PAM uses configuration files to decide which modules to run when a user tries to authenticate. These configurations usually live in /etc/pam.d/, with one file per service, for example /etc/pam.d/sshd for SSH logins or /etc/pam.d/sudo for sudo usage.
PAM separates different aspects of authentication into control types. The most important for policies are auth for user authentication, account for account checks such as expiration and access time, password for password changes, and session for session setup and teardown. Each line in a PAM file specifies which module is used for a particular control type, plus options that define the policy you want.
PAM makes it possible to change policies globally, for example by editing common include files like /etc/pam.d/common-auth on Debian based systems, or per service by editing the individual service file. Changes to PAM can easily lock users out, especially from remote services, so you should test carefully, ideally from an already established root session.
Changing PAM configuration incorrectly can lock you out completely. Always keep a root shell open while testing changes and have console or recovery access available.
Password Complexity and Quality Controls
Password authentication is the default method on many systems, and password policies define how strong those passwords must be.
On many distributions, password quality is enforced through PAM modules such as pam_pwquality.so or, on some older setups, pam_cracklib.so. These modules are referenced in the password section of PAM configuration files and receive options that describe the policy.
Typical controls include minimum length, requirement for different character classes, and checks against simple or common passwords. While exact configuration can differ, the logic remains similar.
A simple mathematical way to think about password strength is to consider the number of possible passwords. If you have an alphabet of size $A$ and password length $L$, then the number of possible passwords is:
$$N = A^L$$
Increasing $A$ by requiring more character types, or increasing $L$ by requiring longer passwords, both increase $N$ and make brute force attacks harder.
You can usually control parameters like minlen, dcredit for digits, ucredit for uppercase letters, lcredit for lowercase letters, and ocredit for other symbols. Negative values often mean at least that many characters of the given class are required.
Strong password policy should balance security with usability. Extremely strict rules can encourage users to write passwords down or reuse predictable patterns.
Password policies also include how passwords are stored. Modern systems hash passwords with algorithms such as SHA-512 with salt, and may allow configuration of algorithm and rounds through tools like authconfig or appropriate configuration files. Policies should avoid outdated hashing schemes such as plain MD5 without strengthening.
Account and Login Restrictions
Authentication policies also cover when and from where a user may log in. These controls are usually applied through PAM account type modules and through some traditional configuration files.
One common approach is to restrict access based on user, group, or service. For example, you can permit only certain users to log in through SSH, or prevent particular accounts from using console logins, even if their password is correct.
Some policies apply time restrictions, where a user’s login is allowed only during specific hours or days. In such setups, the policy checks the current system time whenever a user attempts authentication. If the time is outside the allowed range, authentication fails regardless of password correctness.
Other policies apply terminal or host based restrictions. Terminal restrictions look at which device or virtual terminal a user is logging into. Host restrictions look at client address for network services. In many systems, configuration files like /etc/security/access.conf or /etc/securetty cooperate with PAM modules to enforce these policies.
You can also impose limits on the number of sessions a user can have at once. A policy might allow only a single graphical session for a user or a limited number of shell sessions. These rules prevent resource abuse and can help administrators keep control over multi user servers.
Account Lockout and Failed Login Handling
Account lockout policies define what happens when repeated authentication failures occur. These are critical for slowing automated password guessing attacks.
PAM modules such as pam_tally2 on some systems, or pam_faillock on others, track failed login attempts. They maintain counters per account and sometimes per source IP address. Policy parameters then control how many failures are allowed before an account is locked temporarily or, less commonly, until an administrator resets it.
A typical policy might be to allow a small number of failed attempts within a defined time window and then lock the account for a few minutes. This imposes a delay on brute force attempts while still allowing legitimate users to recover from occasional typing errors.
Lockout policies often define both a failure threshold and an unlock time. If you denote failure threshold by $F$ and unlock time by $T$, then an attacker is limited to roughly $\frac{F}{T}$ guesses per unit of time for a single account. Lowering that value reduces attack speed significantly.
Some policies distinguish between local and remote logins, allowing more lenient behavior on physical consoles while enforcing stricter rules for remote services like SSH.
Overly aggressive lockout policies can create a denial of service risk. An attacker can intentionally cause lockouts for many accounts by repeatedly failing passwords, preventing legitimate users from logging in.
As an administrator, you should also know where failed attempts are logged. System logs hold valuable information about which accounts are failing authentication and from which sources, and they are critical for security monitoring and incident response.
Session Limits and Resource Controls
Authentication policies often work together with session and resource limits. These limits define how much of the system a user can consume once authenticated.
Such limits are commonly configured through files like /etc/security/limits.conf and are enforced through PAM session modules like pam_limits. These modules apply settings like maximum number of open files, maximum processes per user, and memory constraints at login time.
Resource controls can prevent a single user or process from exhausting system resources, such as opening too many files or creating too many processes. While this overlaps with general system administration, the connection to authentication is that the limits are applied as part of the login process and are specific to authenticated identities.
You can also define soft and hard limits. Soft limits are applied by default but can be relaxed by the user up to the hard limit. This gives some flexibility while preserving a strict upper bound.
Session Management and Idle Policies
Besides resource limits, authentication policies can include session duration rules and idle time policies. These govern how long an authenticated session may exist and when it should be terminated automatically.
Idle timeout policies are often enforced by shells or terminal settings, which log out or lock sessions after a given period of inactivity. Display managers and screen savers on graphical environments can lock the screen after idle time as part of local security policy. On the terminal, environment variables and shell options can support automatic logout, although that is more of a shell configuration topic.
Session duration limits might be applied to higher privilege activities. For example, a sudo policy might cache successful authentication for a limited period before prompting for the password again. This limits how long elevated privileges remain easily accessible without reauthenticating.
In many cases, these behaviors depend on settings in sudoers or similar configuration, coupled with PAM modules that control when and how reauthentication is requested.
Idle and session duration policies should reflect the risk level of the environment. Shared or publicly accessible systems benefit from shorter timeouts, while personal single user systems may need more relaxed settings for usability.
Centralized Authentication and Local Policy
Many Linux systems, especially in organizations, do not authenticate users only against local /etc/passwd and /etc/shadow files. Instead, they may rely on centralized directories such as LDAP, Active Directory, or external identity providers. PAM again acts as the mediator, loading modules that talk to these back ends.
In such setups, there is a separation between identity source and local policy. The identity source determines which users exist, their credentials, and often group memberships. The local system still applies its own policies on top of that, such as which services those users can access, local session limits, and resource controls.
Tools like SSSD or NSS modules connect system user lookup to network directories, while PAM modules handle authentication. Policy decisions such as who may log in via SSH, who may use sudo, and which time or host restrictions apply remain under control of local configuration files, even if the identities themselves are remote.
For administrators, this means an authentication policy has two major parts, central rules at the identity provider level and local rules at each Linux system enforced via PAM and related configuration. You must ensure these two levels work together and do not contradict each other.
Designing Practical Authentication Policies
When you design authentication policies for a Linux system, you need to balance security, usability, and administrative overhead.
For personal workstations, policies might focus on strong passwords or passphrases, screen locking behavior, and maybe simple account lockout for repeated failures. For multi user servers exposed to networks, you typically harden password policies, apply strict lockout behavior with care, restrict which accounts can log in remotely, and integrate with monitoring for failed attempts.
Important aspects to decide include the minimum password length and complexity, whether you will permit or forbid password based remote logins in favor of key based methods, how many failed attempts are allowed, how long lockouts last, and which users or groups may access which services.
You also need a procedure for recovery. This includes how administrators unlock accounts, how users reset forgotten passwords, and how you respond to suspicious authentication activity seen in logs.
Authentication policies are effective only if they are consistently enforced across all access paths. A single forgotten service that allows weak or no authentication can undermine otherwise strong policies on the system.
By understanding PAM, password quality controls, account restrictions, lockout behavior, session limits, and the interaction with centralized identity systems, you can define and maintain authentication policies that protect your Linux systems while keeping them usable for legitimate users.