Using AD to Authenticate UNIX Users

Configuring AD
Configuring AD to support pam_ldap is simple and straightforward. You first need to create a guest account as the LDAP bind account (as I described earlier), then give the account only Domain Guests privilege with a strong password. Next, create a global group, such as UNIX-System1, for the UNIX system, then add to the group all users who need to access the system. For AD to support LDAPS, you must install Win2K Certificate Services or a third-party certificate server on at least the DCs that pam_ldap uses. In my implementation, I used Win2K Certificate Services server and used a global public policy to let all DCs automatically receive a certificate. For more information about using Win2K Certificate Services, see "Using Win2K Certificate Services to Configure a Standalone CA, Part 1," January 2002, http://www.secadministrator.com, InstantDoc ID 23373.

Configuring PAM
The last crucial step you need to take before your users can use AD accounts to log on to the UNIX system is to configure PAM to let UNIX services and applications use AD authentication. PAM provides four management functions: authentication (auth), account, session, and password. The authentication function sets up user credentials and authenticates users, the account function validates the user's account (e.g., checks for password and account expiration), the session function sets up and terminates logon sessions, and the password function manages password changes. You need to configure each of these four management functions in the pam.conf file. Every entry for each management function in pam.conf contains a service or application name, followed by the management function, control flag, authentication library path, and option. Web Listing 2 (http://www .secadministrator.com, InstantDoc ID 39989) contains a sample pam.conf file to help explain PAM configuration.

A service or application name can be the name of any PAM-aware UNIX service or application. In Web Listing 2, login in the first field is for system console logon; other includes all other PAM-aware services and applications, including telnet, ftp, ssh, su, and sudo. If you want to use one or more specific authentication modules for a service or application (e.g., sudo), you can have one or more separate entries for sudo. The second field indicates the management function (i.e., auth, account, session, or password) applied to the service or application.

The third field is a control flag that controls the enforcement of the management function. For example, in the code at callout A in Web Listing 2, the control flag sufficient for the login service means that if the login authentication is successful, the authentication finishes; otherwise, PAM invokes the PAM module that the code at callout B references. Because the control flag in the code at callout B is required, the authentication must be successful before the user can log on to the console.

The fourth field of an entry specifies the PAM module's library path. The library path that the code at callout A specifies points to the pam_ldap library, while the path specified at callout B uses pam_unix (the native UNIX authentication). Therefore, when a user logs on to the system console, the system first authenticates the user against AD; if AD authentication fails, PAM uses the UNIX authentication. The option try_first_pass at callout B means PAM automatically uses the password that the user entered for AD authentication instead of asking the user to reenter the password for UNIX authentication. The option ignore_ unknown_user at callout C means that if the user account doesn't exist in AD, PAM checks the user account in UNIX. This sample pam.conf file lets a user, such as an administrator who's authorized to have physical access to the system, log on to the system console. When the UNIX system loses network connectivity, the administrator can use the local root account to log on to the console for troubleshooting. The script also specifies that all other services (besides login) and applications use only AD for user authentication and account check. Pam_ldap doesn't support session management, so PAM must use UNIX PAM for session management, as the code at callout D defines (which is another reason that you should keep your users' UNIX accounts on the system). The final lines of code specify that if a user account doesn't exist in AD, when the systems administrator or user changes the user's password, PAM changes the password of the user's UNIX account.

Edit and save the pam.conf file in the /etc directory on the UNIX system. You don't need to reboot the system after configuring PAM. The system picks up the change automatically in the next user authentication. Your system is now ready to authenticate UNIX users against AD.

Beyond UNIX User Authentication
AD provides a good, central user-authentication infrastructure for the enterprise. LDAP PAM takes advantage of AD to centralize UNIX user authentication, relieve the administrative burden of password management, free users from memorizing multiple passwords, and implement a strong password policy across Windows and UNIX platforms. Using AD for UNIX user authentication, however, is just the first step toward a unified enterprise user-management system. Remember, you still need to maintain your users' UNIX accounts on UNIX systems even though users don't need to know they still have UNIX accounts. You can further use AD to store and manage user account information for UNIX users and remove the task of repetitive UNIX user administration on individual systems. I'll explore that functionality in a future article. In the meantime, if you'd like to learn more about centralized authentication, see "Centralized Authentication for Windows & Linux," July 2002, http://www.winnetmag.com, InstantDoc ID 25319.