| Downloads |
|---|
| 39989.zip |
Users in a Windows and UNIX-based heterogeneous network often maintain several UNIX accounts to access UNIX systems and applications and an Active Directory (AD) domain account to access Windows resources. This setup has long been an administrative and security concern because users can easily forget passwords if they have many accounts or if they don't use the accounts frequently. As a result, users might write down passwords on paper and leave the paper on the desk if they have to remember many passwords. To help secure these environments, some organizations use UNIX's Network Information Service (NIS) to maintain a central user account database for multiple UNIX systems so that a user can use the same account to log on to different UNIX systems. As security becomes more important, however, many organizations want to have a strong password policy on both Windows and UNIX platforms to better secure their information systems.
A strong password policy in AD must include password aging and locking, in addition to password complexity and history. AD's password complexity requires that a password contain three of the four available character types: lowercase letters, uppercase letters, numbers, and symbols, with a minimum password length of six characters. AD's password history requires that users don't reuse a password for an administrator-set number of passwords (e.g., the past 10 passwords). Unfortunately, most UNIX and Linux OSs and NIS don't natively support AD's level of password complexity and history, although they support the password complexity of at least two lowercase or uppercase letters and at least one number or symbol. They also require that the password history of the new password differ from the old one by at least three characters. Some third-party user authentication and account management products can implement a strong password policy across multiple platforms, but they're expensive and complicated to implement. Microsoft Windows Services for UNIX (SFU) supports implementing NIS on AD domain controllers (DCs) and using the AD user object to store the user's UNIX user properties and credentials, but the user's UNIX password is still separate from the AD password.
The approach I describe in this article is the easiest, fastest, and most economical solution to centralizing UNIX user authentication by AD. This setup lets UNIX users use their AD domain accounts to log on to UNIX systems (requiring each user to remember only one password ) and enforces AD's strong password policy on UNIX systems.
Introducing PAM
Almost all UNIX and Linux OSs now use Open Software Foundation's (OSF's) Pluggable Authentication Module (PAM) architecture. PAM lets you easily integrate into UNIX systems various authentication technologies such as UNIX, Lightweight Directory Access Protocol (LDAP), Kerberos, and smart cards for PAM-aware applications and services such as login, passwd, rlogin, telnet, and ftp. PAM-aware services and applications don't authenticate users; instead, specific PAM modules perform the authentication. By default, a UNIX system uses UNIX PAM to authenticate users against the UNIX passwd and shadow passwd files that store user account and password information. With PAM, however, you can easily add and use alternative PAM modules and let other systems perform user authentication according to your application and security needs. For example, LDAP PAM enables user authentication through an LDAP directory, such as AD, Novell eDirectory, OpenLDAP, and Sun Microsystems' Sun ONE Directory Server. Kerberos PAM lets users authenticate through a Kerberos Distribution Center (KDC), such as Heimdal Kerberos, Massachusetts Institute of Technology (MIT) Kerberos, Sun Enterprise Authentication Mechanism (SEAM), and Windows 2000 Kerberos. Note that PAM provides authentication, but not authorization, for the system resources that a user can access after logging on.
Because you have an existing Win2K AD infrastructure and users use their AD domain accounts to log on to Windows every day, you can leverage AD-to-UNIX user authentication through either LDAP PAM or Kerberos PAM. Therefore, users need to know only one account's logon credentials to access their Windows and UNIX systems. At the same time, you can enforce the same AD strong password policy for both AD and UNIX users. For more information about configuring AD password policies, see Getting Started with Win2K, "Password Defense," September 2002, http://www.winnetmag .com, InstantDoc ID 25962.
When I compared LDAP PAM and Kerberos PAM, I found LDAP PAM easier to implement for both Windows and UNIX administrators. LDAP PAM is almost transparent to AD but requires some easy-to-follow configuration on UNIX systems. Let's take a closer look at the LDAP PAM implementation with AD. For information about Win2K's Kerberos for UNIX user authentication, see the Microsoft article "Step-by-Step Guide to Kerberos 5 (krb5 1.0) Interoperability" (http://www .microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp).
Understanding LDAP PAM
LDAP PAM (pam_ldap) is an open-source freeware program. PADL Software, the company that developed pam_ldap as a library, maintains the program's source code and enhances its functionality. Most UNIX vendors bundle PADL's pam_ldap or their own pam_ldap libraries in their OS releases. The most recent Linux distributions also include pam_ldap.
LDAP PAM manages UNIX user authentication to LDAP directories. It uses the UNIX LDAP client or a third-party version such as OpenLDAP to communicate with the LDAP directory. If your UNIX OS natively supports Secure Sockets Layer (SSL) or runs third-party SSL software such as OpenSSL, and your LDAP client and directory support SSL, LDAP PAM can use LDAP over SSL (LDAPS) to secure communication between the UNIX system and the LDAP directory. AD automatically supports LDAPS if you've installed server certificates on your AD DCs. Let's look at the authentication process from LDAP PAM to AD, which the PAM architecture in Figure 1 shows.
When a PAM-aware service or application authenticates a user (e.g., when a user telnets to a UNIX host), it invokes the PAM library. The PAM library calls the authentication module that the service or application needs to use according to the PAM configuration specified in a file named pam.conf. (I guide you through configuring PAM later.) LDAP PAM then uses the communication specifications defined in the ldap.conf file to submit the user's logon information to AD. AD's LDAP service then compares the user's logon information and the corresponding user's credentials in AD and applies AD password policy to authenticate the user.
Before the user can log on to the UNIX system after authentication, the system must establish a user environment that includes the UNIX user's ID number, home directory, and default shell. These user attributes, which aren't part of the user attributes in AD, are generated when you create the UNIX account and stored in the local passwd file or on the NIS server. Therefore, you still need to keep your users' UNIX accounts on each UNIX system; however, your users no longer need to know their UNIX account logon credentials or even know that they own an account on the local system. In short, you can configure PAM to let users use only their AD accounts, rather than their UNIX accounts, to log on to the system.
Installing LDAP PAM
You can find the pam_ldap library file, often named pam_ldap.so.1 or pam_ ldap.so, in the /usr/lib/security directory on most UNIX systems, but this version is often older than the pam_ldap file available from PADL. Earlier versions often won't work with AD because they weren't built to support or understand AD. Unless your UNIX vendor's pam_ldap works with AD, I suggest that you either download the current version of pam_ldap from PADL (http://www.padl.com/OSS /pam_ldap.html) and compile it yourself or obtain the binary package from Symas (http://rebec.symas.net/download/connexitor), a consulting company.
During the implementation of pam_ldap on a Sun Solaris 2.8 system (a popular UNIX version), I found that Solaris 2.8's pam_ldap didn't work with AD, but PADL's pam_ldap 164 (the most recent version) works well with AD. If you plan to build pam_ldap on Solaris 2.8, you can perform the steps below (users on a non-Solaris system might need to modify these instructions). The software I use to compile and support pam_ldap is all open-source freeware.
- Make sure you have the GNU Compiler Collection (Gcc), make, automake, and autoconf tools to generate executables. You use the tools to build pam_ldap and its dependencies. You can download the most recent stable version of Gcc 3.3 from http://www .gnu.org/directory/gnu/gcc.html, make 3.80 from http://www.gnu.org/ directory/gnu/make.html, automake 1.76 from http://www.gnu.org/directory/gnu/automake.html, and autoconf 2.57 from http://www.gnu.org/directory/gnu/autoconf.html. Gcc, make, automake, and autoconf's binary packages are also available at http://www.sunfreeware.com.
- Download and install a random number generator that SSL can use to generate encryption keys. A good example is Pseudo Random Number Generator Daemon (PRNGD) 0.9.27. You can get the tool's source code from http://www.aet.tu-cottbus.de/ personen/jaenicke/postfix_tls/prngd .html or get the binary package of version 0.95 from http://www.sunfreeware.com.
- Download and install the most recent version of OpenSSL 0.9.7b to support SSL. The source code is available from http://www.openssl.org. A binary package is also available at http://www .sunfreeware.com.
- Download the OpenLDAP 2.1.22 source code from http://www.openldap .org/software/download. Before you compile OpenLDAP, set up the environment settings by using the following commands:
export LDFLAGS CPPFLAGS unset LD_LIBRARY_PATH LDFLAGS="-L/usr/local/ssl/lib -L/usr/local/lib" LDFLAGS="$LDFLAGS -R/usr/local/ssl/lib:/usr/local/lib" CPPFLAGS="-I/usr/local/ssl/include -I/usr/local/include"
Next, use the following commands from the OpenLDAP source-code directory to compile and install the OpenLDAP's client component and the LDAPS function that pam_ldap uses:./configure -disable-slapd -with-tls make depend make make install
- Use the following commands to compile and install pam_ldap 164 from the pam_ldap directory:
./configure -with-ldap -lib=openldap -with-ldap- dir=/usr/local -with-ldap-conf- file=/etc/ldap.conf
The flags in the configure command tell pam_ldap to use OpenLDAP's LDAP functions and LDAP configuration from the /etc/ldap.conf file. The installation places the pam_ldap.so.1 file in the /usr/lib/security directory.
Configuring LDAP PAM
Before you can use pam_ldap, you need to configure the ldap.conf and pam .conf files on the UNIX system. You also need to configure AD on Win2K. PADL provides a sample file of ldap .conf and pam.conf with the pam_ ldap source code, but you need to customize the files for your environment. Let's look at the ldap.conf file configuration first, then look at the AD and pam.conf configuration.
Web Listing 1 (http://www.secadministrator.com, InstantDoc ID 39989) shows the sample ldap.conf file that I used to configure pam_ldap access to AD. The code at callout A in Web Listing 1 specifies the search base of the LDAP distinguished name (DN—i.e., your complete AD organization name string) and tells LDAP to search objects and attributes from the search base down through all child organizations until it finds or can't find the object within the user-defined search time limit—in this case 30 seconds.
The code at callout B shows the AD LDAP server Uniform Resource Identifiers (URIs) for the DCs that pam_ldap will use. (When you specify multiple DCs, as the example shows, the authentication can fail over to the next available DC if the current one isn't available.) LDAPS encrypts the LDAP communication to secure the user credentials passing over the wire from the UNIX system to AD. The code at callout B also tells LDAPS to use TCP port 636 and specifies the LDAP server version—AD supports LDAP 3.0, the most recent version.
Next, the code gives the LDAP bind DN and password used to log on to AD within the bind time limit (e.g., 30 seconds) and performs LDAP user object and attribute lookup for UNIX user authentication. The LDAP bind logon account can be a guest user account in the Domain Guests group that has no other access privileges. You can't use AD's anonymous account because the account can't look up the sAMAccountName attribute of the user object that pam_ldap authentication requires. AD lets you define a group and include only those users authorized to log on to the UNIX system. The code at callout C specifies that pam_ldap lets only those users who are members of the group Unix-System1 log on to the system. This group-membership control prevents an unauthorized user in AD from logging on to the system in the event that you forgot to delete the user's old UNIX account or you accidentally created the user's account on the system. The last line of code in Web Listing 1 denotes that the user password is an AD password.
You can create your own ldap.conf file by replacing the sample names in the code with the appropriate names from your system. Then, save the file in the \etc directory on your UNIX system and protect the file by letting only the root account read to or write to it.
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.
