Section 39.4. Objective 4: PAM Authentication

39.4. Objective 4: PAM Authentication

PAM is the Pluggable Authentication Modules system. It enables the addition of a number of advanced security features across the whole Linux system without the need to recode individual services. All security conscious programs (such as login, su, and ftp) are configured by PAM to do a variety of authentication and security checks.

When a service such as login is used, PAM will check its configuration files to determine how to authenticate the user. For instance, PAM may authenticate by checking shadow passwords, Kerberos, Winbind, Samba, and so on. After the method of authentication is determined, PAM returns an answer to the service to indicate whether the user was authenticated.

39.4.1. PAM Configuration

All the PAM configuration files are located in /etc/pam.d. Every application or service that can use PAM has a file entry in /etc/pam.d as well. Some of the most common entries that can be found under /etc/pam.d include chfn, chsh, halt, linuxconf, login, passwd, ppp, reboot, rexec, rlogin, rsh, shutdown, su, xdm, and xscreensaver. If installed, you may even find KDE, Samba, and SSH here as well. Looking at these files, you will see four columns of information: module-type , control-flag, module-path, and arguments. Take a look at the following example of the login entry under /etc/pam.d:

 #%PAM-1.0 auth      required   /lib/security/pam_securetty.so auth      required   /lib/secuirty/pam_pwdb.so     shadow nullok auth      required   /lib/security/pam_nologin.so account   required   /lib/security/pam_pwdb.so password  required   /lib/security/pam_cracklib.so password  required   /lib/security/pam_pwdb.so nullok use_authtok session   required   /lib/security/pam_pwdb.so session   optional   /lib/security/pam_console.so

The following subsections describe each field.

39.4.1.1. module-type

There are currently four types of modules that you will find under the module-type column in your PAM configuration files, shown inTable 39-5.

Table 39-5. Module types
Module	Description
`auth`	This module type provides two ways of authenticating the user. First, it establishes that the user is indeed who the user claims to be. It does this by instructing the application to prompt the user for a password. The module can then grant group membership (independent of /etc/groups) or other privileges through its credential granting properties.
`account`	This module restricts authentication-based account management. It is typically used to restrict or permit access to a service based on the time of day, the maximum number of users, or even the location of the user (for instance, allowing user root to log in only from the console).
`session`	This module performs duties that need to be done for the user before she can be given access. Services that are affected by this include the logging of information about a user, mounting directories, and so on.
`password`	This module is required for updating the authentication token associated with each user. There is typically one module for each challenge or response, based on the authentication (`auth`) module type.

39.4.1.2. control-flag

The control-flag column is used to indicate how the PAM library reacts to the success or failure of the module with which it is associated. The four flags that are used to specify the module actions are shown in Table 39-6.

Table 39-6. Control flags
Flag	Description
`optional`	This flag marks the module as not being critical to the success or failure of the user's application for service. In fact, Linux-PAM will ignore such a module when determining whether the module stack succeeds or fails.
`required`	This indicates that the success of the module is required for the module-type facility to succeed. But if this module fails, the failure will not be apparent to the user until all the modules of the same module type have been executed.
`requisite`	This is similar to `required`, but if this module fails, control is immediately returned to the application. This flag is useful to protect against the possibility of a user being allowed to enter a password over an unsafe medium.
`sufficient`	This indicates that the Linux-PAM library is satisfied that this module type has succeeded in its purpose. If no previous module has failed, no more stacked modules of this type are invoked. If this module fails, the result is not deemed fatal to the application.

39.4.1.3. module-path and arguments

The module-path is the pathname to the dynamically loadable module. The default directory containing the module defaults to /lib/security, unless another path is mentioned. Typically, the full path /lib/security is listed regardless.

The argument column of each entry lists arguments that are passed to the module when the module is invoked. Typically, these arguments are optional and are specific to each given module. If an argument is invalid, the module ignores it. If such an error is made, the module is required to write the error to syslog, the system log daemon. The five generic arguments that are often used and understood by most modules are shown in Table 39-7.

Table 39-7. Arguments
Argument	Description
`debug`	Use the syslog call to log debugging information to the system log files.
`no`_warn	Instruct the module not to give warning messages to the application.
`try`_first_pass	The module should attempt authentication with the previously typed password from the preceding `auth` module. If that does not work, the user is prompted for a password.
`use`_first_pass	The module should not prompt the user for a password. Instead, it should obtain the previously typed password from the preceding `auth` module. If that does not work, the user will not be authenticated.
`use`_mapped_pass	Instructs the module to take the clear text authentication token entered by a previous module and use it to generate an encrypted (or decrypted) key to safely store or retrieve the authentication token required for the module. The `use_mapped_pass` argument is not currently supported by any of the modules in the Linux-PAM distribution because of possible consequences associated with U.S. encryption restrictions. Developers within the United States (or their own country) may implement it freely within their country.

A special argument listed in the example for auth was shadow. This refers to support for shadow passwords, which is supported by pam_pwdb.so. Shadow passwords utilize several methods to increase system security. They make system password files more difficult to break into for system password information, by replacing the password field of /etc/passwd (with an x) and creating the file /etc/shadow, readable only by root, to contain the password hash.

39.4.2. LDAP Client Authentication Using PAM

One of the best uses of LDAP is to centralize your authentication information base. It makes user administration easier and smarter. The authentication method should be changed in the PAM mechanism, and you need to change the way to search the tree where the user's information (password, UID, GID, home, shell) is placed. Multiple client platformsSolaris, Linux, AIX, and so oncan use an LDAP server for authentication

Tip: The following examples require a fully functional OpenLDAP server, a posix account object already created in your directory, and properly working client-side queries.

39.4.2.1. Packages for LDAP and PAM

Two packages are needed to get LDAP auhentication working:

nss_ldap: Used by nsswitch.conf to retrieve information from LDAP servers
pam_ldap: The PAM module that can be used to take advantage of LDAP in many PAM-aware applications

Both are available under GPL license at the maintainer's site, www.padl.com. The configuration, compilation, and installation process is simple and can be determined from the site's documentation.

Debian, Red Hat, and many other distributions make available precompiled nss_ldap and pam_ldap packages.

39.4.2.2. Configuring nss_ldap and nsswitch.conf

With the packages installed, change the nsswitch.conf file to the following:

 passwd:         files ldap group:          files ldap shadow:         files ldap

To test whether nss_ldap is retrieving LDAP information, try:

 # getent passwd  ... (you should see the /etc/passwd  accounts here) cxp7:x:2645:347:JACQUELINE:/u/cxp7:/bin/bash d026:x:1130:672:CARLOS:/u/d026:/bin/bash ima3:x:548:224:PIERRE:/u/ima3:/bin/bash ...

39.4.2.3. Configuring pam_ldap and /etc/pam.d files

Now change the /etc/pam.d/login file:

 auth     required        pam_securetty.so auth     required        pam_nologin.so auth     sufficient      pam_ldap.so auth     required        pam_unix_auth.so try_first_pass account  sufficient      pam_ldap.so account  required        pam_unix_acct.so password required        pam_ldap.so session  sufficient      pam_ldap.so session  required        pam_unix_session.so

For users who log in using Gnome Display Manager, the file /etc/pam.d/gdm has to be modified:

 auth     sufficient     pam_ldap.so auth     required       pam_nologin.so auth     required       pam_env.so auth     required       pam_unix_auth.so account  sufficient     pam_ldap.so account  required       pam_unix_acct.so password required       pam_ldap.so session  sufficient     pam_ldap.so session  required       pam_unix_session.so

There are many configurable files under /etc/pam.d. It's possible to authenticate FTP, su, SSH, and lots of other stuff over LDAP. This is outside the scope of LPI, however.