LDAP System Administration [Electronic resources] نسخه متنی

6.4 The pam_ldap Module

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_ldapl. 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

6.4.1 Configuring /etc/ldap.conf

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.

nss_base_XXX  base?scope?filter

nss_map_XX  rfc2307item  mapped_item

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.