7.3 Transparent Kerberos Login with PAM

When a user logs into his workstation at the beginning of the day, we want that user to acquire a Kerberos Ticket Granting Ticket when he enters his credentials. We'll call this transparent Kerberos login. Windows 2000, XP, and 2003 automatically acquire tickets upon login when the user is part of a Windows domain. However, for other systems, we have to configure this step manually. In Unix, the simplest and most portable way to get initial credentials for a user upon login is through the Pluggable Authentication Modules (PAM), which is available on most operating systems. Using PAM, you can acquire Kerberos tickets for logins that occur on the system's console (and any other network-based protocol, but we want to avoid sending passwords over the network).

Historically, applications such as the console login program and the X Windows System login program (xdm) all had to be modified to support new authentication methods. This introduces a maintenance and security nightmare, as locally-maintained patches must be made to system software to enable authentication methods other than the standard Unix password file. Worse yet, if the operating system comes without source, you may not even be able to replace the program with one that performs the necessary authentication method.

PAM solves this problem by providing a standard plug-in interface that both application developers and authentication method developers can write to. A mapping file is created that maps applications' authentication requests to the appropriate authentication methods, so that authentication modules can be added and removed on the fly, without recompiling the application. Linux, FreeBSD, Solaris, and HP-UX all include PAM support, and more operating systems are adding support.

However, PAM is not a panacea. It only supports traditional username and password authentication, so PAM works best when authenticating local (ie., on the console) login requests. Network-based services should use native Kerberos authentication to take advantage of the single-sign-on capabilities of Kerberos and to avoid sending plain text passwords across the network. PAM cannot provide native Kerberos authentication through the Kerberos ticket exchange. In addition, PAM implementations differ slightly from vendor to vendor, so PAM modules that may work on one vendor's OS may not work on another vendor's OS. The differences are usually small enough that they can be easily worked around, but it is something to be aware of when using PAM.

More Information About PAM The following Unix operating system vendors have web sites that describe their support of the PAM framework: HP-UX: http://www.hp.com/products1/unix/operating/security Solaris: http://wwws.sun.com/software/solaris/pam Linux: http://www.kernel.org/pub/linux/libs/pam FreeBSD: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pam The Linux-PAM page at http://www.kernel.org/pub/linux/libs/pam/ is also a good resource. A list of available PAM modules is maintained at http://www.kernel.org/pub/linux/libs/pam/modules.html.

With the introductions out of the way, let's examine how to set up PAM to support Kerberos 5 logins. There are several PAM modules providing Kerberos authentication support, and unfortunately, they're all named pam_krb5. We'll pick one to work with; we'll use the pam_krb5 module available from http://www.nectar.cc/krb, as it is well supported and integrated into the Linux-PAM distribution. If your operating system already includes a precompiled pam_krb5, by all means, use it. However, if you have to compile your own pam_krb5, use this one.

Depending on your site's use of Kerberos, you can configure pam_krb5 to either require valid Kerberos credentials to login, or only to acquire Kerberos tickets if the user's Kerberos password matches some other password that is required to login to the local system (for example, a local password database).

Remember that Kerberos only provides an authentication service; hosts that use PAM to authenticate local users will still need an authorization database, which could be a local /etc/passwd file, or a network-wide directory service such as NIS, LDAP, or NetInfo. If you are requiring users to login with valid Kerberos passwords, the directory that you choose should not include any password information for the users.

7.3.1 Configuring PAM

PAM is typically configured through a single configuration file, /etc/pam.conf, or a directory of configuration files representing services that use PAM for their authentication needs. The exact location of the configuration files and their search order varies from implementation to implementation; "man pam" should point you in the right direction.

PAM delegates the task of logging a user into a system to a series of individual modules. Each PAM module provides a distinct set of services to any PAM-enabled application; for example, a Unix password file module may provide the ability for an application to authenticate and authorize access against a Unix password file. A Kerberos 5 PAM module provides authentication support and session establishment support. Applications can call the PAM modules through a standardized API, so that regardless of the underlying authentication mechanism, the API visible to the application remains the same.

PAM further subdivides the task of authenticating and authorizing a user to log into a system into four distinct tasks: account authorization, authentication, password services (such as password changing), and session establishment and teardown. Each PAM module can implement one or more of these tasks.

The PAM configuration (which can be either a monolithic file or a set of files in a directory) serves the purpose of attaching modules to PAM-enabled applications. Therefore, an administrator can specify a PAM module that an application uses to validate potential clients. Figure 7-1 shows the relation between applications, PAM modules, and the PAM configuration file.

Figure 7-1. PAM architecture

However, confining administrators to a single authentication mechanism per application is limiting. For example, while it may be useful for machines to authenticate against a Kerberos 5 KDC, there are certain users, such as root, that you'd like to keep in a local password file instead of in a centralized database. Another example is a fail-safe login ability; in the case of network failure or if the authentication servers are unreachable, it is definitely useful to have a small local password database with administrative users so that you can still access the machine. Therefore, PAM supports multiple authentication sources for a given application. PAM refers to this as stacking.

Stacking PAM modules provides for quite a lot of flexibility in configuration, at the cost of some complexity. Specialized PAM modules (such as a PAM module to check if the potential users' shell, located in /etc/shells) can be created to further limit access to services.

Let's take a look at an example PAM configuration, for the telnet service:

auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        sufficient    /lib/security/pam_krb5afs.so use_first_pass tokens
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so

password    required      /lib/security/pam_cracklib.so retry=3 type=
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    sufficient    /lib/security/pam_krb5afs.so use_authtok
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so
session     optional      /lib/security/pam_krb5afs.so

Note that this example assumes a PAM configuration directory, with each service represented by a separate file contained inside. If your system uses a monolithic PAM configuration file, then there is an additional field: the service name that is prepended to every line in the configuration file.

The first field is the PAM task. We briefly discussed the four tasks that PAM defines above; let's take a closer look at them.

auth

The auth task handles the actual authentication of the user. PAM modules that implement the auth task take in a username and password from the user and return a code determining whether the password is valid for the given user.

account

The account task performs what the PAM documentation refers to as account management. Most of the functions that the PAM documentation associates with this task can also be referred to as authorization related tasks. These include determining whether the user's password has expired and whether the user is permitted access to this service.

password

The password task handles password changes for the user.

session

Modules implementing the session task provide services that should be performed before a service is given and before the user disconnects from the session. An example would be writing audit trail entries to a log file.

As you can see in the above example, the stacking of PAM modules is based on the task; every task for every service can have several PAM modules associated with it. The second field, known as the control field, indicates how the failure of a given module affects the outcome of the task as a whole. Traditionally, the control field has four valid values:

required

Success of this module is required for the authentication process to succeed. If this module returns failure, other modules are still executed, but the authentication process will fail regardless. In addition, PAM does not specify the order in which modules marked required are executed, except in the case of intervening modules marked requisite and sufficient. This is done for security reasons, to avoid giving attackers detailed information on failed authentication attempts.

requisite

Failure of this PAM module immediately terminates the authentication process. If this module fails, no module listed after this one is executed.

sufficient

The success of this PAM module immediately causes the authentication process to succeed. If this module succeeds, no module listed after this one is executed.

optional

This module is ignored unless it is the only module for this particular authentication task.

Newer versions of the PAM framework support a more complex syntax for the control field. For more information and to determine what your particular vendors' PAM system supports, check your system's manual page for "pam".

The next field is the name of the PAM module, which can either be expressed as an absolute path or relative to the default directory for modules. The last field is a list of arguments for the module. The arguments vary from module to module but there are some generic options recognized by most modules:

debug

Log debugging information to syslog for this module; this option is useful for troubleshooting PAM configurations.

use_first_pass

If a preceding authentication module has already obtained a password, try authentication using that password. If authentication using that password fails, then the module returns failure.

try_first_pass

First try authentication using the password passed from the preceding authentication module. If that fails, then prompt the user for a new password and attempt authentication with it.

The pam_krb5 PAM module also recognizes the following options:

forwardable

When obtaining a TGT for the user, request forwardable tickets from the KDC.

ccache= name

When creating the credential cache upon successful authentication, create it with the name specified by name. The name argument must be in the form of type:residual, where type is the type of credential cache, typically FILE. residual is the location of the cache, which in the case of the FILE type is a filename. There are two special tokens accepted for this argument, namely %u, which is replaced with the user ID of the authorized user, and %p, which is replaced by the current process ID.