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.
Previous
Register
