Configure Pluggable Authentication Modules (PAM)

• The Role of PAM

Attach:pam1.png

Linux uses Pluggable Authentication Modules (PAM) in the authentication process as a layer between users and applications. A Linux system administrator can use these modules to configure the way programs should authenticate users.

PAM provides system-wide access to applications through authentication modules. Individual applications do not need to include their own authentication routines. PAM takes care of that task for them.

For example, when a user logs in to a Linux system from a virtual terminal the user runs a process called login. The login process requests the user's login name and password. The password is hashed and then compared with the hashed password stored in an authentication database via PAM. If the hashed passwords are identical, login grants the user access to the system by starting the user's login shell.

If other authentication procedures are used, such as smart cards, all programs that perform user authentication must be able to work with these smart cards. Before PAM was introduced, each individual application, such as login, FTP, or SSH, would have to be extended to support the smart card reader.

Fortunately, PAM makes things easier. PAM creates a software bridge with clearly defined interfaces between applications (such as login) and the current authentication mechanism. If you install a smart card reader, you can install a new PAM module to enable authentication using this new device. After adjusting the PAM configuration for your applications, they can make use of this new authentication method.

Third-party vendors can also supply additional PAM modules to enable specific authentication features for their products, such as the PAM modules that enable Novell's Linux User Management (LUM) authentication with eDirectory.

PAM Configuration Files

• Programs that use PAM:

• PAM modules

PAM provides a variety of modules—each one with a different purpose. For example, one module checks the password, another verifies the location of the terminal the system is accessed from (such as local or remote), and another reads user-specific settings.

Every program that uses PAM authentication has its own configuration file in the /etc/pam.d/ directory. Each file is named after the service is represents. For example, the configuration file for the passwd program is called /etc/pam.d/passwd.

There is one special configuration file in this directory named other. This file contains default configuration parameters that are used if no application-specific file is found.

In addition, there are global configuration files for most PAM modules in /etc/security/. These files define the exact behavior of the PAM modules. Examples include access.conf, limits.conf, pam_env.conf, and time.conf.

Every application that uses a PAM module actually calls a set of PAM functions. These functions are implemented in modules which perform the authentication process according to the information in the various configuration files and then return the result to the calling application.

PAM Configuration File Example

• Default configuration file for the login program:

Attach:pam2.png

• auth requisite pam_nologin.so

Checks whether a /etc/nologin file exists. If such a file is found, its content is displayed when a user tries to log in. Login is denied for all but the root user.

• auth [options] pam_securetty.so

Checks the /etc/securetty file for a list of valid login terminals. If a terminal is not listed in that file, the login is denied from that terminal. This concerns only the root user.

• session required pam_loginuid.so

The pam_loginuid module sets the loginuid process attribute for the process that was authenticated. This is necessary for applications to be correctly audited. This PAM module should only be used for entry point applications like: login, sshd, gdm, vsftpd, crond and atd.

• session optional pam_lastlog

pam_lastlog is a PAM module to display a line of information about the last login of the user. In addition, the module maintains the /var/log/lastlog file.

• session optional pam_mail.so

Displays a message if any new mail is in the user's mail box. It also sets an environment variable pointing to the user’s mail director

PAM Configuration File Syntax

• Each line in a PAM configuration file contains 3 columns plus optional arguments as shown:

Attach:pam3.png

Module Types

• Different module types cover different aspects of authentication and authorization

Provides two means for authenticating the user: Establish that the user is who he claims to be by instructing the application to prompt the user for a password or other means of identification. Grant group membership or other privileges through credential-granting properties.

Performs non-authentication account management tasks. They are typically used to restrict or permit access to a service based on the time of day, currently available system resources (such as the maximum number of users), or even the location of the user (such as limiting root login to the console).

Performs tasks that need to be done before users can be given access to a service or after a service is provided. This could include logging user information or mounting directories.

Update the authentication token associated with the user. Typically, there is one module for each challenge/response-based authentication (auth) module type.

Control Flag

• The control flag indicates how PAM responds to the success or failure of a module:

Same as [success=ok new_authtok_reqd=ok ignore=ignore default=bad]. A module with this flag must be successfully processed before the authentication can proceed. After the failure of a module with the required flag, all other modules with the same flag are processed before the user receives a message about the failure of the authentication attempt. This prevents users from knowing at what stage their authentication failed.

Same as [success=ok new_authtok_reqd=ok ignore=ignore default=die]. A module with this flag must also be processed successfully. If successful, other modules are subsequently processed, just like modules with the required flag. However, if it fails, the module gives immediate feedback to the user and no further modules are processed. You can use the requisite flag as a basic filter, checking for the existence of certain conditions that are essential for a correct authentication. This flag can be used to protect against the possibility of a user getting the opportunity to enter a password over an unsafe medium. It is conceivable that such behavior might inform an attacker of valid accounts on a system. This possibility should be weighed against the not insignificant concerns of exposing a sensitive password in a hostile environment.

Same as [success=ok new_authtok_reqd=ok default=ignore]. The failure or success of a module with this flag does not have any direct consequences. You can use this flag for modules that are intended only to display a message (such as telling a user that mail has arrived) without taking any further action.

Same as [success=done new_authtok_reqd=done default=ignore]. After a module with this flag has been successfully processed, the application receives an immediate message about the success and no further modules are processed (provided there was no preceding failure of a required module). The failure of a module with the sufficient flag has no direct consequences. All subsequent modules are processed in their respective order.

This is not really a control flag but indicates that the keyword in the next column is to be interpreted as a filename relative to /etc/pam.d/ that should be included at this point, such as commonaccount, commonauth, commonpassword, or commonsession.

• Modules of the same type (such as auth) are executed in a series (called stacking) from top to bottom of the configuration file. The control flags determine what happens on success or failure of a module and thus determine the relative priority of each module.
• The control flags used to be limited to required, requisite, optional, and sufficient, but since SLES 11 SP2 have been supplemented by a more fine-grained approach with a syntax of [value1=action1 value2=action2 ...]
• Values include

• Actions include

Values and Actions are explained in the pam.d manual page and in more detail in the Linux-PAM System Administrators’ Guide that is available in the /usr/share/doc/packages/pam/ directory.

Modules and Arguments

• The PAM modules are located in the /lib64/security/ directory. Every filename of a module starts with the prefix pam_. You do not need to include the path as long as the module is located in the default directory (/lib64/security/).
• Some PAM modules can be used for multiple module types. For example, pam_unix.so can be used for both auth and password.
• Arguments (options): You can include options in this column for the module, such as debug (enables debugging) or nullok (permits user access to a service if the user's password is blank - the default is to not allow access if the password is blank).

Include Files

It is recommended to use pamconfig to modify the common* files. The modules perform the following tasks:

• auth required pam_env.so

Used to set additional environment variables. The variables can be configured in the /etc/security/pam_env.conf file.

• auth optional pam_gnome_keyring.so

Gnome keyring can automatically unlock the 'login' keyring when the user logs in.

• auth required pam_unix.so

Used during the authentication process to validate the login and password provided by the user.

A manual page is provided for each module; to get more information on, for instance, on the pam_unix.so module, enter man pam_unix.

Configure PAM Authentication

• pamconfig: Utility to add/remove pam modules to/from the PAM stack
• Examples:

pam-config --list-modules

pam-config --add --ldap

pam-config --delete --krb5

The effect of, for instance, pam-config --add --ldap, is that lines are added to the /etc/pam.d/common* files, such as this for common-auth:

auth required pam_ldap.so use_first_pass

The options are different, depending on the module type (auth, session, ...).

Secure Password Guidelines

• Simple passwords can be cracked within minutes:

Bad password: too simple

PAM Documentation Sources

PAM documentation is available:

• In the /usr/share/doc/packages/pam/ directory:

• In PAM module man pages

System Security Services Daemon

• SSSD then can talk to remote directory services that provide user data

YaST includes the Authentication Client module that helps with defining authentication scenarios. Start the module by selecting Network Services > Authentication Client. The YaST Authentication Client is a shell for configuring the System Security Services Daemon (SSSD). SSSD then can talk to remote directory services that provide user data, and provide various authentication methods. This way, the host can be both, an LDAP or an Active Directory (AD) client. SSSD can locally cache these user data and then allow users to use of the data, even if the real directory service is (temporarily) unreachable. An NSS (Name Service Switch) and PAM (Pluggable Authentication Module) interface are also available.

First you must configure at least one authentication domain. A authentication domain is a database that contains user information. Click Add.

• Configure Authentication Domain, an identity provider, and an authentication provider

As the Name of the New Domain enter an arbitrary name (alphanumeric ASCII characters, dashes, andunderscores are allowed). Then select one of the available identification providers and finally select the authentication provider to be used for that domain. For example, if you want to access an LDAP directory with kerberos authentication, select ldap as the identification provider and krb5 as the authentication provider and leave Activate Domain enabled

In the next step you see that id_provider and auth_provider are properly selected, must set some mandatory parameters for these providers.

For more information and additional configuration options you can set via the New button, see the context Help and the SSSD man pages such as sssd.conf (man sssd.conf) and sssd-ldap (man sssd-ldap). It is also possible to select later all parameters available for the selected identification and authentication providers.

If you use LDAP, TLS is mandatory. Do not select ldap_tls_reqcert, if an official certificate is not available.

• SSSD provides following identification providers:

• Supported authentication providers are: