Objectives

After completing this section, students should be able to explain how PAM works and interpret the effect of settings in existing PAM configuration files.

Describing PAM

The Pluggable Authentication Modules system, or PAM, provides a generic way for applications to implement support for authentication and authorization.

Initially, an application that wanted to authenticate users used the local /etc/passwd and /etc/shadow files. Eventually, other authentication mechanisms were invented. For example, your company might decide to implement Kerberos, in which case the application must verify the correctness of the passwords against the KDC. Alternatively, you may choose to deploy an LDAP infrastructure, and this time the application must contact the LDAP server for authentication.

This meant that every time a new authentication method came up, applications had to be rewritten to support it. Each application was handled separately, there was a lot of duplication of effort, and many different implementations that had to be audited for correctness.

PAM provides a generic way for applications to implement support for authentication and authorization. A PAM-enabled application calls the PAM library, libpam, to perform all authentication tasks on its behalf and return a pass or fail response to the application.

The PAM modules implement the different authentication methods. For example, the pam_krb5 module performs authentication against Kerberos. The pam_ldap module authenticates against an LDAP server. The pam_unix module uses the standard local files, /etc/passwd and /etc/shadow. The PAM-enabled applications can directly use these authentication methods without having to be modified or recompiled.

Administrators can use PAM configuration files to select the modules to use for each application.

The following figure provides an overview on how PAM-enabled applications authenticate users.

Figure 5.1: PAM authentication

In this figure, the login program contacts PAM for authentication. PAM reads the /etc/pam.d/login configuration file to retrieve the list of modules to use for authentication. PAM calls the modules, stored in /usr/lib64/security/, and these modules perform the authentication. PAM returns to the login program a successful authentication status. The vsftpd FTP server also uses PAM to authenticate FTP users, but in the figure, the user provides incorrect credentials, and PAM returns a fail code to vsftpd.

Describing Authentication and Authorization

Determining whether a client should have access to a resource is a 2-step process. First, the application must authenticate the client. That is, it must prove that the client is who they claim to be.

Then the application must determine whether or not that client is allowed access. That process is called authorization.

For example, a user who types the correct user name and password at a login prompt has authenticated. However, access control restrictions may not authorize that user from logging in right now, and the user may be dropped back to the login prompt.

PAM manages both authentication and authorization.

Configuring PAM

The majority of the PAM configuration files are in /etc/pam.d/, although some modules use additional configuration files in /etc/security/. PAM stores its binary modules responsible for evaluating criteria in the /usr/lib64/security/ directory.

Each PAM-enabled application has its own PAM configuration file in /etc/pam.d/, and generally this file has the same name as the application: /etc/pam.d/login for the login program, or /etc/pam.d/sshd for the sshd daemon for example. If the service file for an application is missing, PAM uses /etc/pam.d/other by default.

These configuration files contain rules that specify the modules to call for authentication and authorization. This way administrators can configure different authentication methods per application. In practice, you usually want all your applications to use the same authentication method. To achieve that, most of the configuration files use the include or substack directives to include the password-auth or system-auth files, also in the /etc/pam.d/ directory.

[root@demo ~]# grep -e include -e substack /etc/pam.d/login
auth       substack     system-auth
account    include      system-auth
password   include      system-auth
session    include      system-auth

[root@demo ~]# grep -e include -e substack /etc/pam.d/sshd
auth       substack     password-auth
account    include      password-auth
password   include      password-auth
session    include      password-auth

With this organization, your applications share the same authentication methods, and it is easy to maintain a consistent set of PAM tests. Administrators only have to manage the system-auth and password-auth files, and rarely have to edit the individual service configuration files. Also, the authconfig command provides a simple and error-free way to edit those two files. The authconfig command is covered in more detail in a later section.

Network services configuration files, such as sshd or vsftpd, include password-auth. Local services configuration files, such as login or sudo, include system-auth. This allows for a different configuration for local and network services. For example, you configure fingerprint and smart card authentication in system-auth, because these authentication methods only pertain to local services.

Describing the PAM Configuration File Syntax

Application configuration files in /etc/pam.d/ follow a standard format for their rules:

type  control module [module arguments]

The following output shows the /etc/pam.d/system-auth file as an example.

[user@demo ~]$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_localuser.so
account     sufficient    pam_succeed_if.so uid < 1000 quiet
account     required      pam_permit.so

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so

The first field is the type, and organizes the tests into four management groups: auth, account, password, and session. The application invokes each group at a different time during a user authentication and authorization process.

The order of the rules in a management group is essential because PAM rules are parsed and executed from top to bottom.

A dash (-) character in front of a type, such as "-session" near the end of the /etc/pam.d/system-auth file, indicates to silently skip the rule if the module file is missing.

Notice that some modules, such as pam_unix, can be called in multiple management groups. When PAM calls these modules, they know in which group they are running and adapt their behavior accordingly.

The next field, the control field, determines how the associated test affects the group's overall result. There are many different possible values for this field, but the most common ones are shown below.

The next field is the PAM module itself. You can give the full path to the module but you usually only give the relative name; PAM looks for the modules in the /usr/lib64/security/ directory.

Modules return a code that PAM interprets as either success or error. PAM modules may also take options or arguments to alter their behavior. Not every module takes arguments, and options or arguments are usually unique to a specific module.

Using SSSD and PAM

The System Security Services Daemon (SSSD), introduced in Red Hat Enterprise Linux 6.0, allows user authentication against remote directories and authentication services such as LDAP, Kerberos, Active Directory, and Red Hat Identity Management.

When a remote user authenticates on the local system, SSSD stores their credentials and authentication parameters to a local cache. This way, even if the remote authentication server is not reachable, the remote user can still log in to the local system. This feature is particularly useful for laptops disconnected from the company network but also helps reduce the load on the remote authentication services.

PAM also provides modules for authenticating to LDAP (pam_ldap), Kerberos (pam_krb5), and other authentication services, but does not have the extra SSSD features. These specific PAM authentication modules are now considered legacy and the preferred method is to use SSSD through the pam_sss module.

You can use the authconfig command to enable SSSD in PAM:

[user@demo ~]# yum -y install sssd
...output omitted...
[user@demo ~]# authconfig --enablesssd --enablesssdauth --update

Accessing the PAM Documentation

The primary source of documentation is the manual pages. Most of the modules have a dedicated manual page with the following information:

For example, the pam_unix module is documented by the pam_unix(8) manual page. Notice that the manual page names do not include the .so module extension.

The pam.conf(5) man page describes the full syntax of the PAM configuration files.

The PAM man pages typically start with the pam_ prefix. The man -k pam_ command returns a long list of related man pages.