Section 8.4. Configuring Linux to Use LDAP for Login Authentication


8.4. Configuring Linux to Use LDAP for Login Authentication

At this point, your LDAP server should be running and should contain account information for your site. In order to do any good, though, you must be able to use that LDAP server for user authentication. In the case of Linux systems, this entails configuring the Pluggable Authentication Modules system and the Name Service Switch system to interface with LDAP. This requires understanding the basic relationships between these systems, installing necessary modules, and configuring the modules.

To use Windows as an LDAP login client, consult the Section 8.5.


8.4.1. LDAP, PAM, and NSS

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.

8.4.2. Basic LDAP Client Configuration

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 OpenLDAP package also includes a configuration file called ldap.conf, but this file is likely to reside in the same directory as slapd.confusually /etc/openldap.


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.

8.4.3. Configuring the LDAP NSS Modules

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

As with PAM configuration files, the /etc/nsswitch.conf file varies from one distribution to another. If yours contains entries instead of or in addition to the files entry, the safest course is to add ldap to the end of whatever entries already exist. (The compat source is common with distributions based on glibc 2.3, for instance.) If you want LDAP to replace an existing authentication tool, though, you can remove the reference to that old tool.


If you want to use LDAP to take over additional duties, you can add ldap to additional appropriate lines in /etc/nsswitch.conf. If you add ldap to the hosts line, for instance, the system attempts to use LDAP for hostname resolution. Of course, such configurations require adding appropriate directory entries to the LDAP server, much as you added user accounts to the server.

8.4.4. Configuring the LDAP PAM Modules

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

Modifying your PAM configuration modifies how Linux authenticates you. A mistake can result in an inability to log into the computer. For this reason, I recommend modifying these files one at a time, leaving at least one known-working login tool unmodified. This way, if you create a nonfunctional service, you'll still be able to log in using another tool to correct the problem. Backing up the original files can also help you recover from such an error.


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.

8.4.5. Verifying Proper Functioning

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.



    Linux in a Windows World
    Linux in a Windows World
    ISBN: 0596007582
    EAN: 2147483647
    Year: 2005
    Pages: 152

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net