6.5 The nss_ldap Module

The Name Service Switch (NSS) is similar to PAM except that it only provides a mechanism for information retrieval. PADL Software's nss_ldap module can be obtained from http://www.padl.com/OSS/nss_ldap.html. The current implementation can be used on AIX, HP-UX, Linux, and Solaris. Although the pam_ldap module supports FreeBSD and Mac OS 10.2, the nss_ldap library does not. This means that you will not be able to apply the complete solution outlined in this chapter to those platforms.

Compiling PADL's nss_ldap module is almost the same as compiling pam_ldap. The same options are available to the configure script (for explicitly defining the LDAP libraries to be used and their locations). The one additional compile-time setting that you will use is -enable-rfc2307bis. This change optimizes the search parameters for each nsswitch.conf database by using the nss_base_* parmeters. Otherwise, nss_ldap would query for entries by performing a subtree search beginning at the base (from /etc/ldap.conf). The familiar three-step:

$ ./configure  --enable-rfc2307bis
$ make
$ /bin/su -c "make install"

installs an appropriately named version of the nss_ldap library in /lib. For example, the resulting file would be /lib/libnss_ldap.so on a Linux host and /lib/nss_ldap.so on a Solaris box. Since the examples in this chapter are based on Linux systems, whenever there is a need to refer to the actual nss_ldap library file, I will use the libnss_ldap.so filename.

The nss_ldap module uses the same /etc/ldap.conf configuration file as PADL's pam_ldap module. The configuration parameters for this module are summarized in Table 6-3. While both pam_ldap and nss_ldap read /etc/ldap.conf for configuration settings, the parameters prefixed by pam_ do not affect the behavior of nss_ldap.

The /etc/ldap.conf file must be readable by any process that performs any of the various getXbyY( ) function calls such as getpwnam(jerry) or getgrgid(0). For example, if you have specified a host to which all LDAP queries should be directed, but the user's process is unable to obtain that parameter setting because it cannot read ldap.conf, you will begin to notice DNS SRV queries for _ldap._tcp.domain as the nss_ldap library attempts to locate an LDAP server. However, if you make the ldap.conf file world-readable, think twice about putting a binddn and bindpw in the file.

To configure a service to use the nss_ldap module, add the keyword ldap to the appropriate lines in your /etc/nsswitch.conf file. PADL's NSS module currently supports the following databases:

passwd

group

hosts

services

networks

protocols

rpc

ethers

netgroups

The following databases are currently unsupported:

netmasks

bootparams

publickey

automount

Mount point lookups using LDAP queries are supported directly by some automount agents, such as Sun's automounter (included with current Solaris releases) and Linux's autofs. This will be covered later in the chapter.

Here's an excerpt from an nsswitch.conf file. It specifies that the system should consult the local password, shadow password, and group files before querying the directory server.

## Define the order of lookups for users and groups.
passwd:     files ldap 
shadow:     files ldap
group:      files ldap

Because your directory stores groups in one ou and user accounts in another, you can help reduce the load on your LDAP server by customizing the searches used by nss_ldap. Table 6-3 listed several nss_base_XXX parameters. You will use only the three that correspond to the nsswitch.conf ldap entries just listed. Each search needs to be only a one-level search since all relevant entries are stored directly below the corresponding ou (e.g., ou=people and ou=group).

## Optimize the nss_ldap searches for these databases.
nss_base_passwd   ou=people,dc=plainjoe,dc=org?one
nss_base_shadow   ou=people,dc=plainjoe,dc=org?one
nss_base_group    ou=group,dc=plainjoe,dc=org?one

If all has gone well up to this point (user and group account information has been entered into the LDAP directory, and libnss_ldap.so has been installed and configured), the following command should list the accounts in /etc/passwd first, followed by any posixAccount objects in the directory:

$ getent passwd 
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
< . . . output deleted . . . >
gcarter:x:780:100:G. Carter:/home/queso/gcarter:/bin/bash
jerry:x:782:782:Jerry Carter:/home/queso/jerry:/bin/bash

The last two lines of output were retrieved from the LDAP server. The "x" in the password field is due to the presence of the shadowAccount object class, as shown in this LDIF listing of the account information for gcarter:

dn: uid=gcarter,ou=People,dc=plainjoe,dc=org
uid: gcarter
cn: Gerald (Jerry) Carter
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
loginShell: /bin/bash
uidNumber: 780
gidNumber: 100
homeDirectory: /home/queso/gcarter
userPassword: {crypt}GoYLwzMD6cuZE

If the shadowAccount object class wasn't present, the nss_ldap module would have filled in the second field of the output from getent with the password hash (assuming this attribute was returned from the directory server).

If no posixAccount entries are returned by the getent command, then verify that the nss_ldap library was installed correctly, that it has the read and execute permissions set for everyone (chmod o+rx /lib/libnss_ldap.so*), and that /etc/ldap.conf is readable by all users (chmod o+r /etc/ldap.conf). If all of these appear to be correct, also verify that the information can be retrieved from the directory using ldapsearch.