Pluggable Authentication Modules (PAM) are implemented as shared libraries that distance applications from the details of account data storage, mechanisms used to authenticate users, and service authorization processes. PADL Software has developed a pam_ldap module, supported on FreeBSD, HP-UX, Linux, Mac OS 10.2, and Solaris, as part of a reference implementation for RFC 2307. This module allows you to take advantage of LDAP in PAM-aware applications and operating systems. You can download the pam_ldap source code from http://www.padl.com/OSS/pam_ldap.html. Most Linux distributions include PADL’s pam_ldap and nss_ldap modules with the operating system. You should remove these packages first if you plan to build the latest version from source.
The pam_ldap and nss_ldap libraries included with Solaris as part of the operating system installation are Sun’s own creation and should not be confused with the modules discussed in this chapter.
Once you have obtained and extracted the pam_ldap source code, building the module is a familiar process:
$ ./configure $ make $ /bin/su -c "make install"
PADL’s PAM and NSS libraries can make use of the Netscape LDAP SDK and the original University of Michigan LDAP SDK, in addition to the OpenLDAP client libraries. The configure script attempts to determine which of these packages is installed on the local system. If you need to inform the configure script which LDAP client libraries you have installed and where, use the following configure options:
--with-ldap-lib=type select ldap library [auto|netscape3| netscape4|umich|openldap] --with-ldap-dir=DIR base directory of ldap SDK
The pam_ldap module (and as we will see shortly, PADL’s nss_ldap module) stores its configuration settings in a text file. This file is named ldap.conf by default and is normally stored in the /etc directory. The configuration parameters you can put in this file are summarized in Table 6-1, Table 6-2, and Table 6-3; the list is fairly small and self-explanatory. We will begin customizing this file by exploring how a client locates the LDAP server and authenticates itself.
Parameter |
Description |
The IP address (or hostname) of the LDAP server. The value must be
resolvable without LDAP support. If a host is not specified, the
nss_ldap library will attempt to locate an LDAP server by querying
DNS for an SRV record for
_ldap._tcp.<domain>. The current version
of the pam_ldap module (v157) will not perform this auto-lookup, but
support is planned for a future release. Also refer to the
| |
The base DN to use in searches. | |
The version of LDAP to use when querying the server. Legal values are
| |
The DN to use when binding to the LDAP server. This is an optional parameter; it is necessary when access control on directory entries prohibits anonymous searches. | |
The password used when binding to the LDAP server (if the
| |
The port to use when contacting the LDAP server. The default is port
389. Also refer to the | |
This parameter allows you to map the effective UID 0 (i.e., the root UID) to a DN that is used to bind to the LDAP server. If enabled, the password for this DN is read from /etc/ldap.secret. This follows the convention that the root account should be able to access all information on the system. | |
This parameter defines the behavior of the PAM and NSS modules for
negotiating SSL when binding to the server. By default, SSL is not
used. The client can be configured to use LDAPS by setting this
parameter to | |
The scope to use when searching the LDAP tree. The possible values
are | |
This option accepts an LDAP URI defining the host and port of the directory server. |
Parameter |
Description |
A Boolean parameter (defaults to | |
A string that provides additional filter elements that are ANDed with
( | |
The attribute that should be matched against the user’s login name. This parameter lets you use something other than a simple username for authentication—for example, an email address. | |
A Boolean parameter ( | |
Defines the DN of a group whose membership (see the
| |
Defines the group membership attribute. | |
|
These two parameters accept an integer representing the minimum and
maximun |
This parameter defines various methods for changing passwords on LDAP
servers. It supersedes the older |
In order for the pam_ldap module to offer any help, it
must be able to locate the directory server it will query for
information. There are two ways that the module can locate the
directory server. The sole method supported by pam_ldap is to
explicitly specify the LDAP server using the
host
or
uri
parameters in
ldap.conf. The alternative, utilized only by the
nss_ldap library, is to omit the host parameter and create a DNS SRV
record that maps the hostname
_ldap._tcp.<domain> to an IP address. If
no host is specified in ldap.conf, the nss_ldap
library tries to look up a server with this special hostname and uses
that server at that address for queries. If you have multiple
servers, you can configure round-robin load sharing with either
approach.
The following parameters instruct pam_ldap to contact the host ldap.plainjoe.org on the default port 389 for all LDAPv3 queries:
# Your LDAP server. Must be resolvable without using LDAP. uri ldap://ldap.plainjoe.org/ ## Set the version number for LDAP commands. The default is to use Version 3 if ## supported by the client libraries. ldap_version 3
Next, you must define the search parameters for pam_ldap to use when querying the directory. These options correspond to the standard ldapsearch command-line options. The following fragment of ldap.conf defines the search base, the search scope, and a maximum time limit:
## Define the search base base dc=plainjoe,dc=org ## Define the scope of the search [sub|base|one]. A subtree search is the default. scope sub ## Set a time limit in seconds to wait on a search. timelimit 30
The DN of the user’s entry must be located in order
to bind to the directory on behalf of the user and thus perform the
requested authentication. This search can be done either anonymously
or by using a predefined
binddn
and
bindpw
. The bindpw
string
must be stored in ldap.conf as clear text, which
always makes me nervous. Therefore, my preference is for the first
option. Because anonymous searches are implied by the absence of a
specified binddn
, no additional
ldap.conf parameters are required.
Finally, add a few parameters to fine-tune the search filter.
pam_login_attribute
defines which attribute
should be matched to the login name entered by the user.
pam_filter
allows an administrator to further
refine the search filter when attempting to locate a user account. In
the following configuration file entries, it is specified that the
user’s login name should be matched against the UID
attribute defined in the posixAccount
object
class. (Note that a UID in this schema is a login name, not a number,
as in common Unix usage.)
## Define the user login name attribute (defaults to uid). pam_login_attribute uid ## The following filter will be used to AND with <pam_login_attribute>=%s. pam_filter objectclass=posixAccount
With these two settings, the pam_ldap library makes the following search to verify that a user account named “carter” is in the directory:
(&(objectClass=posixAccount)(uid=gcarter))
After verifying the existence of the DN, the PAM module attempts to bind to the directory using the located DN and the password entered by the user. If this bind succeeds, pam_ldap informs the calling application that the user has been successfully authenticated.