scope
The scope to use when searching the LDAP tree. The possible values are sub, one, and base.
uri
This option accepts an LDAP URI defining the host and port of the directory server.
Table 6-2. pam_ldap ldap.conf parameters
Parameter
Description
pam_check_host_attr
A Boolean parameter (defaults to no) that controls checking of the host attribute when authorizing a login.
pam_filter
A string that provides additional filter elements that are ANDed with (uid=%s) when attempting to validate a user. See the pam_login_attribute parameter for related information.
pam_login_attribute
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.
pam_lookup_policy
A Boolean parameter (yes or no) that tells pam_ldap whether to contact the root DSE to get the server's password policy. For use with Netscape's directory server 3.x only.
pam_groupdn
Defines the DN of a group whose membership (see the pam_member_attribute parameter) should be used to restrict access to the local host.
pam_member_attribute
Defines the group membership attribute.
pam_min_uid
pam_max_uid
These two parameters accept an integer representing the minimum and maximun uidNumber values allowed to log in. The default is to place no restrictions on logins.
pam_password
This parameter defines various methods for changing passwords on LDAP servers. It supersedes the older pam_crypt, pam_nds_passwd, and pam_ad_passwd parameters. Possible values include: clear (the default; sends the clear text of the password to the server), crypt (hashes the password locally using the standard crypt( ) function before sending the change to the server), md5 (generates the MD5 hash of the password locally before sending it to the server), nds, racf (provides support for changing passwords stored in a Novell Directory Server), ad (provides support for changing passwords stored in an Active Directory server), and exop (supports the Password Modify extended operation defined in RFC 3062; implemented by OpenLDAP).
Table 6-3. nss_ldap ldap.conf parameters
Parameter
Description
nss_base_shadow
nss_base_passwd
nss_base_group
nss_base_hosts
nss_base_services
nss_base_networks
nss_base_protocols
nss_base_rpc
nss_base_ethers
nss_base_netmasks
nss_base_aliases
nss_base_netgroup
These parameters allow the naming contexts for various databases in nsswitch.conf to be configured as per the recommendations from the RFC 2307 updates. The syntax is:
nss_base_XXX base?scope?filter
The filter is combined with the default filter for the object being requested using a logical AND (&). These parameters are available only when nss_ldap has been configured to use the —enable-rfc2307bis option at compile time.
nss_map_attribute
nss_map_objectclass
These parameters provide a means of mapping attributes and object classes returned from the directory server to an RFC 2307-equivalent schema item. The syntax is:
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.
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_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.
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.
OpenSSH, PAM, and NSS
Once the pam_ldap and nss_ldap shared libraries have been installed and /etc/ldap.conf has been configured, you can configure individual services to use the new PAM module. We'll start with the SSH daemon, sshd . Here's how to set up OpenSSH (http://www.openssh.com/ ) on a Linux system, which uses a separate PAM configuration file per service. (Note that other systems may use a single PAM file for all services; for example, Solaris uses /etc/pam.conf.) Make sure that PAM is enabled when you compile the sshd daemon; otherwise, you will be wasting your time.
The following /etc/pam.d/sshd configuration file defines the pam_ldap library to be used for authentication (auth) and account management (account). The account management library checks for password aging according to the attribute types defined for the shadowAccount object class and verifies any host-based access rules (covered in the next section). The session module type is ignored by the pam_ldap library. While user password changes are supported by the pam_ldap library, these are not relevent to this example.
## /etc/pam.d/sshd
## PAM configuration file for OpenSSH server
auth required /lib/security/pam_nologin.so
auth sufficient /lib/security/pam_ldap.so
auth required /lib/security/pam_unix.so shadow nullok use_first_pass
account sufficient /lib/security/pam_ldap.so
account required /lib/security/pam_unix.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_unix.so nullok use_authtok shadow
session required /lib/security/pam_unix.so
session optional /lib/security/pam_console.so
The use of the sufficient control flag for the auth and account service types indicates that authentication by this module alone is enough to return success to the invoking application. The use_first_pass argument is necessary so that the user is not prompted for an additional password if authentication falls through to the pam_unix.so library.
You will have to create a similar configuration file for every other service for which you want to control access.
While configuring sshd to use PAM for authentication requires some configuration, nothing needs to be done to make sshd use the nss_ldap library. The retrieval of information from the various databases listed in /etc/nsswitch.conf is handled by the system's standard C library; once you've set up nsswitch.conf, you're done. The client application only needs to call the basic get . . . ( ) function, such as getpwnam( ), to obtain the available information.
Authorization Through PAM
Once a user has been authenticated, the account management features of the pam_ldap module provide two means of restricting access to a host, independent of any other PAM modules you may have specified in the configuration file (e.g., the pam_nologin module). Which method you choose depends on whether you wish to bind a host to a group of users or bind a user to a group of hosts.
One Host and a Group of Users
The first authorization method, in which you specify a group of users who are allowed to use a particular host, ties into other information you have already migrated into the directory. The host entry for a machine (generated from /etc/hosts by the PADL migration scripts) can be extended to include a list of DNs
for users (member) that are authorized to log on using pam_ldap. The following LDIF example shows how you can use the extensibleObject class to associate a group of users with a host entry:
dn: cn=pogo,ou=hosts,dc=plainjoe,dc=org
objectClass: ipHost
objectClass: device
objectClass: extensibleObject
ipHostNumber: 192.168.1.75
cn: pogo.plainjoe.org
cn: pogo
member: uid=gcarter,ou=people,dc=plainjoe,dc=org
member: uid=kristi,ou=people,dc=plainjoe,dc=org
member: uid=deryck,ou=people,dc=plainjoe,dc=org
In order to configure pam_ldap to honor this group membership, the following two lines must be added to /etc/ldap.conf:
## Define the DN of the entry to contain the groupOfUniqueNames.
pam_groupdn cn=pogo,ou=hosts,dc=plainjoe,dc=org
## Define the attribute type that should be used in the attempt to match the user's
## DN.
pam_member_attribute member
For OpenSSH, this configuration means that only those users whose DN is listed as one of the values for the member attribute will be allowed ssh access to your host.
One User and a Group of Hosts
You can also specify the machines that any given user is allowed to access. To implement this control mechanism, the structural account object class listed in the cosine.schema file must be present in the list of object classes for an entry. This is done for you by the PADL migration scripts. Figure 6-6 shows that the account object class requires only one attribute. This attribute, uid, is already required by the posixAccount object class and is therefore guaranteed to be present.
Figure 6-6. Schema for the account object class
While several optional attribute types are available with the addition of this new object class, only the host attribute is of use to pam_ldap. The following LDIF listing shows how the account object class can be used to control access:
LDAP System Administration Page 15