[ Team LiB ] |
![]() ![]() |
7.3 Transparent Kerberos Login with PAMWhen 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.
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 PAMPAM 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
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.
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:
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:
The pam_krb5 PAM module also recognizes the following options:
![]() |
[ Team LiB ] |
![]() ![]() |