In an environment with more than a few Linux servers, managing users, groups, and other information securely across those systems is critical. Pluggable Authentication Modules (PAM) and the Lightweight Directory Access Protocol (LDAP) give administrators a way to accomplish this without having to distribute flat files or rely on RPC services, such as the insecure Network Information Service (NIS).

LDAP is a very mature protocol supported by everyone from Microsoft to IBM and Oracle. And reference implementations, such as OpenLDAP, have been available since the mid-'90s. PAM bridges the gap between traditional Unix and Linux login functionality and LDAP-enabled directory servers without requiring that applications or services be recompiled or reconfigured.

Aside from the obvious benefit of centralized storage and secure access, using LDAP has other key benefits depending on the server technology being used. These benefits generally include more granular password policy support, distributed or delegated administration of different groups of users in the same directory, and generally better performance and scalability than the alternatives.

Getting the Pieces
Most Linux distributions today support PAM out-of-the-box. However, the PAM_LDAP module, which is responsible for connecting the PAM framework to the LDAP-enabled directory service, usually needs to be downloaded and compiled separately. The source can be downloaded at www.padl.com.

PAM_LDAP itself has several dependencies, including SSL, LDAP, and SASL libraries, and it can be finicky about the specific versions used. While it's possible to install without some dependencies, such as SSL, not including them can render the system less secure. The most common issues with deployment are often related to getting a secure version of this module operational.

The directory that will be used to store and access account data is the other major component that will have to be installed. There are many options here and the choice of product is usually made on factors such as price, scalability, performance, and other key characteristics. Besides the base service, most commercial offerings include or have compatible tools to do everything from synchronize with other data sources to graphical user management and user self-service (e.g., password resets). Replicating data between servers and data centers is another key functionality that exists in most products, but in different ways.

LDAP-enabled directories have extensible schema that defines the type of data that can be stored. A standard set of schema, defined in IETF RFC 2307, may have to be imported or created in the directory to support the storage of Linux account information. In addition to accounts, this standard also defines schema for the storage of hosts, netgroups, services, and other types of data that has traditionally been stored in flat files, NIS, and related technology.

Making It Work
Once the modules are installed and the required directory servers are properly configured, the key steps remaining will be to migrate existing account information into the directory server and enable the PAM service.

Fortunately the first step is straightforward, given the ability of free migration tools from the same source as the PAM_LDAP module itself. These migration tools are capable of migrating all major information that would commonly be found in NIS or the equivalent flat files. The output of these files is a format called LDIF that can be used by standard LDAP tools for importing and modifying data in the directory.

With the data in place, the PAM module can be turned on and configured to point to the appropriate directory server. At this stage it's probably a good idea to keep a backup shell to help ensure that a mistake doesn't lock all the users out of the system.

Once authenticated, many applications will still need access to other data normally stored in passwd, group, and other files. This can be solved by configuring the system's name service switch configuration file (nsswitch.conf) to use LDAP. This defines the source and order that data ranging from account information to groups and even host name information will be checked in sources such as NIS, LDAP, and flat files.

Increasing Performance with Caching
Since many servers may be using the same directory, using a local server cache to reduce search and authentication requests may increase both performance and the number of servers that can be used with a single directory. This is especially true when using SSL and other overhead that can put an additional load on the directory servers.

In smaller environments this is less of a concern given that a typical directory server supports thousands of requests per second on modest hardware, but medium and large environments should look at using the Name Service Cache Daemon (NSCD). This service is included in most Linux distributions and requires no serious configuration. That said, it's important to realize that making a change to the directory, such as disabling an account, won't take immediate effect with the cache enabled.

Stronger Password Hashes & Security over the Wire
Many servers still support the CRYPT password hashing algorithm. This algorithm is easy to crack and a stronger algorithm, such as SMD5 or SSHA, should be selected instead. Access controls on the directory should still be configured to limit access to the hashed password.

Enabling either TLS/SSL or using SASL authentication mechanisms is an absolute requirement, since the alternative is to have the PAM module communicate with the LDAP directory server in a way that sends passwords in clear text over the network. Making this work is easier on some Linux distributions than others, but is an absolute must and can be accomplished on any system with the right combination of libraries as indicated in the PAM_LDAP and dependency documentation.

Conclusion
Together, LDAP and PAM provide a secure and scalable way to authenticate Linux users across multiple servers. Sites still using insecure and less scalable technology, such as NIS, can make the move to LDAP easily using existing modules and migration tools. Care needs to be taken to ensure that performance is maintained and that the security benefits of using the directory aren't sacrificed to bad practices such as weak hashing choices and transmitting passwords in the clear.

Useful Links