The PAM and NSS systems are at the core of Linux’s account management. These systems are described in Chapter 7 and in Appendix A. In brief, PAM is a set of libraries that sits between applications and the account database for authentication purposes. Instead of accessing account databases directly, PAM-enabled applications consult PAM. This arrangement enables you to modify your authentication system (such as adding LDAP) with relative ease, by reconfiguring PAM rather than rewriting all the programs that require authentication. Similarly, NSS manages access to nonauthentication account information, such as home directory locations.

In order to configure a Linux system to use LDAP, you must tie LDAP into these two systems. This is done by installing PAM and NSS support modules and by modifying PAM and NSS configuration files to call the LDAP modules.

Most Linux distributions make PAM and NSS modules for LDAP available in one or two packages that are separate from the main LDAP package. Packages that are called pam_ldap and nss_ldap are common, but some variants exist, such as Debian’s libpam-ldap and libnss-ldap.

The PAM and NSS modules both rely on a configuration file called ldap.conf, which is normally stored in /etc. (Instead of a single ldap.conf file, though, Debian uses two: libnss-ldap.conf and pam_ldap.conf, both in /etc. You must make similar changes to both files.) Before configuring PAM- and NSS-specific options, you should load this configuration file into an editor to customize it for your network.

The /etc/ldap.conf file might be installed as part of any number of different packages. Most frequently, it’s installed with the NSS LDAP package, but Debian places its two configuration files in the libnss-ldap and libpam-ldap packages, and SuSE distributes the file in the pwdutils package.

For the basic configuration described earlier in the chapter, you must modify two items, host and base, in the /etc/ldap.conf (or equivalent) file:

host 192.168.1.1
base dc=pangaea,dc=edu

The host item points the LDAP clients to the LDAP server by IP address or hostname. (The system must be able to locate the server without the use of LDAP, so if you’re using LDAP for local hostname resolution, it’s particularly important that you use an IP address.) The base item specifies the base of the directory tree that’s served by your LDAP server.

If you’ve configured your system for high security, you must also set security options. Most importantly, you must uncomment one of two ssl lines:

ssl start_tls
ssl on

The first of these lines tells the client to negotiate TLS encryption after making a connection to the traditional LDAP port (389); the second tells the client to use SSL and connect to the LDAPS port (636). Several other security options also reside in this file; for instance, you can point the tools to a certificate file or directory with the tls_cacertfile or tls_cacertdir options. One of these options is required if you set tls_checkpeer yes, which makes the server refuse connections to a server if it has an unknown certificate.

NSS provides basic account information to the Linux system. It’s controlled via its configuration file, /etc/nsswitch.conf. To tell NSS to use LDAP as part of its operation, you must change just three lines in this file. Specifically, you should look for the lines beginning with the keywords passwd, shadow, and group. Each line contains a list of tools NSS uses to look up account information, and you should add ldap to each of these lines:

passwd:  files ldap
shadow:  files ldap
group:   files ldap

Once you’ve configured /etc/ldap.conf or its equivalent and modified /etc/nsswitch.conf, you can begin telling PAM to use LDAP for authentication of various services. This process is described in Appendix A, so look there for details of PAM configuration. This section describes some LDAP-specific features. In most cases, you’ll modify files in /etc/pam.d; each file is named after the login or account maintenance service you want to adjust.

To add LDAP to the login authentication, you must add a couple of lines to the PAM configuration file for the service you want to use LDAP:

auth     sufficient  /lib/security/pam_ldap.so try_first_pass
account  sufficient  /lib/security/pam_ldap.so

Typically, you’ll modify all your active login services’ PAM modules in analogous ways. These are likely to include login, gdm, xdm, sshd, ftp, and perhaps some others. If your system uses the pam_stack system, though, you may be able to get away with modifying just one file: system-auth. However, you might want to keep some authentication tools local. For instance, you might want to use the local database only for sudo, which is often used to obtain root privileges; if your LDAP directory doesn’t include information on the root account, it obviously won’t be useful for sudo’s typical uses.

At this point, the Linux system should be using the LDAP server for user authentication. One way to check this is to type getent passwd. This command returns user account information. (A similar command, getent group, returns group information.) On a system that uses only its local account files, the result is similar to typing cat /etc/passwd; however, on a system that uses an LDAP server, you should see additional entries for LDAP-accessible accounts. A partial output might look like this:

# getent passwd
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/bin/false
linnaeus:x:500:100:C. Linnaeus:/home/linnaeus:/bin/bash
linnaeus:x:500:100:Carl Linnaeus:/home/linnaeus:/bin/bash

This output reveals an oddity: the user linnaeus has two entries. One entry is in the computer’s local /etc/passwd file; the other originates on the LDAP server. (If the two lines are different, you can tell which is which by comparing the lines to the contents of the local /etc/passwd file.) In this case, no harm comes of this because information from the two sources is identical, aside from the minor detail of the user’s full name. If the entries had different data, though, such as different UIDs or home directories, confusion can result. Thus, it’s best not to duplicate accounts between the LDAP server and the local system. If duplicates do occur, the first one takes precedence. NSS orders accounts according to the order specified on the passwd, shadow, and group lines in /etc/nsswitch.conf, so placing ldap after files in this file gives local files precedence over LDAP entries.

If you’ve been able to verify your LDAP-generated accounts with getent, you can proceed to testing the login tools. Use whatever login tool you’ve modified to use LDAP and try to log in. Try entering accounts that are defined only via LDAP and only via the local account files, to be sure both work. Try entering both correct and incorrect passwords to be sure that the system is correctly handling the case of login failures. If a password is correct for one system (such as LDAP or your local files) but incorrect for the other, the behavior will vary depending on your precise configuration, as described in Appendix A.