Pluggable Authentication Modules (PAM)

Pluggable Authentication Modules (PAM)

Programs that grant users access to a system use authentication to verify each other’s identity (that is, to establish that a user is who they say they are).

Historically, each program had its own way of authenticating users. In Red Hat Enterprise Linux, many programs are configured to use a centralized authentication mechanism called Pluggable Authentication Modules (PAM).

PAM uses a pluggable, modular architecture, which affords the system administrator a great deal of flexibility in setting authentication policies for the system.

In most situations, the default PAM configuration file for a PAM-aware application is sufficient. Sometimes, however, it is necessary to edit a PAM configuration file. Because misconfiguration of PAM can compromise system security, it is important to understand the structure of these files before making any modifications.

Advantages of PAM

PAM offers the following advantages:
a common authentication scheme that can be used with a wide variety of applications.
significant flexibility and control over authentication for both system administrators and application developers.
a single, fully-documented library which allows developers to write programs without having to create their own authentication schemes.

Each PAM-aware application or service has a file in the /etc/pam.d/ directory. Each file in this directory has the same name as the service to which it controls access.

The PAM-aware program is responsible for defining its service name and installing its own PAM configuration file in the /etc/pam.d/ directory. For example, the login program defines its service name as login and installs the /etc/pam.d/login PAM configuration file.

PAM Configuration File Format
Each PAM configuration file contains a group of directives formatted as follows:
<module interface> <control flag> <module name> <module arguments>
Each of these elements is explained in the following sections.
Module Interface

Four types of PAM module interface are currently available. Each of these corresponds to a different aspect of the authorization process:

auth — This module interface authenticates use. For example, it requests and verifies the validity of a password. Modules with this interface can also set credentials, such as group memberships or Kerberos tickets.

account — This module interface verifies that access is allowed. For example, it may check if a user account has expired or if a user is allowed to log in at a particular time of day.

password — This module interface is used for changing user passwords.

session — This module interface configures and manages user sessions. Modules with this interface can also perform additional tasks that are needed to allow access, like mounting a user’s home directory and making the user’s mailbox available.
In a PAM configuration file, the module interface is the first field defined. For example, a typical line in a configuration may look like this:
auth required
This instructs PAM to use the module’s auth interface.
Control Flag

All PAM modules generate a success or failure result when called. Control flags tell PAM what do with the result. Modules can be stacked in a particular order, and the control flags determine how important the success or failure of a particular module is to the overall goal of authenticating the user to the service.

There are four predefined control flags:

required — The module result must be successful for authentication to continue. If the test fails at this point, the user is not notified until the results of all module tests that reference that interface are complete.

requisite — The module result must be successful for authentication to continue. However, if a test fails at this point, the user is notified immediately with a message reflecting the first failed required or requisite module test.

sufficient — The module result is ignored if it fails. However, if the result of a module flagged sufficient is successful and no previous modules flagged required have failed, then no other results are required and the user is authenticated to the service.

optional — The module result is ignored. A module flagged as optional only becomes necessary for successful authentication when no other modules reference the interface.

Module Name

The module name provides PAM with the name of the pluggable module containing the specified module interface. In older versions of Red Hat Enterprise Linux, the full path to the module was provided in the PAM configuration file. However, since the advent of multilib systems, which store 64-bit PAM modules in the /lib64/security/ directory, the directory name is omitted because the application is linked to the appropriate version of libpam, which can locate the correct version of the module.
Module Arguments

PAM uses arguments to pass information to a pluggable module during authentication for some modules.

For example, the module uses information stored in a Berkeley DB file to authenticate the user. Berkeley DB is an open source database system embedded in many applications. The module takes a db argument so that Berkeley DB knows which database to use for the requested service.

The following is a typical line in a PAM configuration. The <path-to-file> is the full path to the Berkeley DB database file:

auth required db=<path-to-file>
Invalid arguments are generally ignored and do not otherwise affect the success or failure of the PAM module. Some modules, however, may fail on invalid arguments. Most modules report errors to the /var/log/secure file.

Sample PAM Configuration Files

The following is a sample PAM application configuration file:

auth required
auth required nullok
auth required
account required
password required retry=3
password required shadow nullok use_authtok
session required
The first line is a comment, indicated by the hash mark (#) at the beginning of the line.

Lines two through four stack three modules for login authentication.

auth required — This module ensures that if the user is trying to log in as root, the tty on which the user is logging in is listed in the /etc/securetty file, if that file exists.

If the tty is not listed in the file, any attempt to log in as root fails with a Login incorrect message.

auth required nullok — This module prompts the user for a password and then checks the password using the information stored in /etc/passwd and, if it exists, /etc/shadow.

In the authentication phase, the module automatically detects whether the user’s password is in the passwd file or the shadow file.
The argument nullok instructs the module to allow a blank password.

auth required — This is the final authentication step. It checks whether the /etc/nologin file exists. If it exists and the user is not root, authentication fails.

account required — This module performs any necessary account verification. For example, if shadow passwords have been enabled, the account interface of the module checks to see if the account has expired or if the user has not changed the password within the allowed grace period.

password required retry=3 — If a password has expired, the password component of the module prompts for a new password. It then tests the newly created password to see whether it can easily be determined by a dictionary-based password cracking program.

The argument retry=3 specifies that if the test fails the first time, the user has two more chances to create a strong password.

password required shadow nullok use_authtok — This line specifies that if the program changes the user’s password, it should use the password interface of the module to do so.

The argument shadow instructs the module to create shadow passwords when updating a user’s password.

The argument nullok instructs the module to allow the user to change their password from a blank password, otherwise a null password is treated as an account lock.

The final argument on this line, use_authtok, provides a good example of the importance of order when stacking PAM modules. This argument instructs the module not to prompt the user for a new password. Instead, it accepts any password that was recorded by a previous password module. In this way, all new passwords must pass the test for secure passwords before being accepted.

session required — The final line instructs the session interface of the module to manage the session. This module logs the user name and the service type to /var/log/secure at the beginning and end of each session. This module can be supplemented by stacking it with other session modules for additional functionality.
[root@server ~]# cd /etc/pam.d/
[root@server pam.d]# ls -l
total 108
-rw-r–r–. 1 root root 192 Nov 20 2015 chfn
-rw-r–r–. 1 root root 192 Nov 20 2015 chsh
-rw-r–r–. 1 root root 232 Aug 18 2015 config-util
-rw-r–r–. 1 root root 293 Jul 27 2015 crond
lrwxrwxrwx. 1 root root 19 Aug 9 20:55 fingerprint-auth -> fingerprint-auth-ac
-rw-r–r–. 1 root root 702 Aug 9 20:55 fingerprint-auth-ac
-rw-r–r–. 1 root root 796 Nov 20 2015 login
-rw-r–r–. 1 root root 154 Aug 18 2015 other
-rw-r–r–. 1 root root 188 Jun 10 2014 passwd
lrwxrwxrwx. 1 root root 16 Aug 9 20:55 password-auth -> password-auth-ac
-rw-r–r–. 1 root root 974 Aug 9 20:55 password-auth-ac
-rw-r–r–. 1 root root 155 Jun 10 2014 polkit-1
lrwxrwxrwx. 1 root root 12 Aug 9 20:55 postlogin -> postlogin-ac
-rw-r–r–. 1 root root 330 Aug 9 20:55 postlogin-ac
-rw-r–r–. 1 root root 144 Jun 10 2014 ppp
-rw-r–r–. 1 root root 681 Nov 20 2015 remote
-rw-r–r–. 1 root root 143 Nov 20 2015 runuser
-rw-r–r–. 1 root root 138 Nov 20 2015 runuser-l
-rw-r–r– 1 root root 36 Feb 16 21:38 screen
lrwxrwxrwx. 1 root root 17 Aug 9 20:55 smartcard-auth -> smartcard-auth-ac
-rw-r–r–. 1 root root 752 Aug 9 20:55 smartcard-auth-ac
lrwxrwxrwx. 1 root root 25 Aug 9 20:50 smtp -> /etc/alternatives/mta-pam
-rw-r–r–. 1 root root 76 Jun 10 2014 smtp.postfix
-rw-r–r–. 1 root root 904 Nov 20 2015 sshd
-rw-r–r–. 1 root root 540 Nov 20 2015 su
-rw-r–r–. 1 root root 202 Nov 21 2015 sudo
-rw-r–r–. 1 root root 187 Nov 21 2015 sudo-i
-rw-r–r–. 1 root root 137 Nov 20 2015 su-l
lrwxrwxrwx. 1 root root 14 Aug 9 20:55 system-auth -> system-auth-ac
-rw-r–r–. 1 root root 974 Aug 9 20:55 system-auth-ac
-rw-r–r–. 1 root root 129 Nov 20 2015 systemd-user
-rw-r–r–. 1 root root 84 Mar 6 2015 vlock
-rw-r–r– 1 root root 335 Mar 31 20:42 vsftpd

[root@server pam.d]# cat login
auth [user_unknown=ignore success=ok ignore=ignore default=bad]
auth substack system-auth
auth include postlogin
account required
account include system-auth
password include system-auth
# close should be the first session rule
session required close
session required
session optional
# open should only be followed by sessions to be executed in the user context
session required open
session required
session optional force revoke
session include system-auth
session include postlogin
-session optional

PAM configuration files have the following syntax:
type control module-path module-arguments


The type token tells PAM what type of authentication is to be used for this module. Modules of the same type can be “stacked”, requiring a user to meet multiple requirements to be authenticated. PAM recognizes four types:

Determines whether the user is allowed to access the service, whether their passwords has expired, etc.

Determines whether the user is who they claim to be, usually by a password, but perhaps by a more sophistcated means, such as biometrics.

Provides a mechanism for the user to change their authentication. Again, this usually their password.

Things that should be done before and/or after the user is authenticed. This might included things such as mounting/unmounting the user home directory, logging their login/logout, and restricting/unrestricting the services available to the user.

In the login config file, we see at least one entry for each type. Since this the program that allows user to login (hence the name :), it’s understandable that it needs to access all of the different types of authentication.

The control token tells PAM what should be done in if authentication by this module fails. PAM recognizes four control types:

Failure to authenticate via this module results in immediate denial of authentication.

Failure also results in denial of authentication, although PAM will still call all the other modules listed for this service before denying authentication.

If authentication by this module is successful, PAM will grant authentication, even if a previous required module failed.

Whether this module succeeds or fails is only significant if it is the only module of its type for this service.

In the configuration file for login, we see nearly all of the different control types. Most of the required modules are (the main authentication module), the single requisite module is (which makes sure the user is logging in on a secure console), and the only optional module is (the module that retrieves information on the user’s most recent login).

The module-path tells PAM which module to use and (optionally) where to find it. Most configurations only contain the module’s name, as is the case in our login configuration file. When this is the case, PAM looks for the modules in the default PAM module directory, normally /usr/lib/security. However, if your linux distribution conforms to the Filesystem Hierarchy Standard (FHS), PAM modules can be found in /lib/security.

The module-arguments are arguments to be passed to the module. Each module has its own arguments. For example, in our login configuration, the “nulok” (“null ok”, argument being passed to module, indicating the a blank (“null”) password is acceptable (“ok”).
[root@server pam.d]# cat password-auth-ac
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required
auth sufficient nullok try_first_pass
auth requisite uid >= 1000 quiet_success
auth required

account required
account sufficient
account sufficient uid < 1000 quiet
account required

password requisite try_first_pass local_users_only retry=3 authtok_type=
password sufficient sha512 shadow nullok try_first_pass use_authtok
password required

session optional revoke
session required
-session optional
session [success=1 default=ignore] service in crond quiet use_uid
session required

[root@server pam.d]# cat password-auth
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required
auth sufficient nullok try_first_pass
auth requisite uid >= 1000 quiet_success
auth required

account required
account sufficient
account sufficient uid < 1000 quiet
account required


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s