PADL's nss_ldap is (according to the man page) a set of C library extensions which allows X.500 and LDAP directory servers to be used as a primary source of name service information. (Name service information typically includes users,hosts, groups, and other such data historically stored in flat files or NIS.)
Setting up authentication for Unix hosts against LDAP is often done using nss_ldap (and nss_ldap is shipped by most linux distributions).
Distribution differences and configuration file locations
By default, nss_ldap shares the /etc/ldap.conf file with pam_ldap, and inherits some configuration from the configuration file for the LDAP library it was built against. However, there are some differences between distributions, as listed in the table below.
|Distribution||Package providing nss_ldap||location of ldap.conf|
Authenticating via nss_ldap
nss_ldap is typically only used to provide information, and not for authenticating users. However, it is possible to do this, and many users do not realise that they are using nss_ldap for authentication, and wonder why authentication breaks when they make a change.
How does this work?
Well, nss_ldap can provide information for any nss database, including shadow. If the following conditions are met, 'getent shadow' will work for users in LDAP, and thus pam_unix will work (as it does for NIS):
- The userPassword is in crypt or md5 (compatible with the hashes expected to be found in /etc/shadow)
- The user running nss_ldap (root in the case of using nscd, the effective uid in all other cases) is configured with credentials of a DN that has read access to userPassword
nss_ldap can be tested by attempting to enumerate a user with any program which uses the nss interfaces. Some examples are:
- getent (e.g. 'getent passwd ldapuser' or 'getent passwd|grep ldapuser')
- id (e.g. 'id ldapuser')