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.