6.11 PADL's NIS/LDAP Gateway

If configuring all your Unix clients to use PAM and installing the various NSS modules is a little more work than your IT shop can bear at the moment, you may prefer the NIS/LDAP gateway solution mentioned at the beginning of this chapter (refer to Figure 6-1 for an illustration). This section examines PADL Software's ypldapd daemon as a migration path from NIS- to directory-based information storage. The following excerpt from the ypldapd(8) manpage describes ypldapd's position within a network:

YPLDAP(8)

ypldapd emulates the equivalent process ypserv by providing an RPC call-compatible interface. Rather than consulting `map' files as ypserv does, however, ypldapd draws its data from LDAP databases.

In theory, ypldapd allows an NIS domain to be replaced with a directory-based solution without any client machines being aware of the change. Even non-Unix NIS clients, such as the Windows NT NISgina DLL, will function correctly. As far as NIS clients are concerned, nothing has changed: they still get their data using the NIS protocol from an NIS server. Where the server gets its data from is another matter.

The ypldapd package is available in binary form for Solaris, Linux, FreeBSD, and AIX, and can be downloaded with a 30-day evaluation license. PADL's web site provides instructions for obtaining a temporary license via an email request. The user's guide is also available online in either Postscript or MS Word format (http://www.padl.com/Products/NISLDAPGateway.html).

Configuring ypldapd is fairly easy. Because it supports the RFC 2307 information service schema, you can use the PADL migration tools described earlier in this chapter to populate the directory with host and user information. PADL includes a copy of its migration tools with the ypldapd distribution. However, you may want to download the latest version separately.

PADL provides installation scripts for ypldapd that can be executed after unpacking the tar archive in /opt/ypldapd. Before beginning the installation, you should have or know:

• A license key for ypldapd

• The hostname of the LDAP server to query

• The base DN used for searches

• The NIS domain name of the ypldapd server

These settings will be stored in /opt/ypldapd/etc/ypldapd.conf. You can use ypldapd's -c option to specify an alternative configuration file. All other configuration files must be located in /opt/ypldapd/etc/. Here's an initial ypldapd.conf:

## NIS domain to serve
ypdomain yp.plainjoe.org
      
## LDAP server
ldaphost 192.168.1.77
      
## Search base
basedn dc=plainjoe,dc=org
      
## Enable caching.
caching on
      
## Dump caches every half hour.
cache_dump_interval 30
      
## Use the default naming context mappings.
namingcontexts namingcontexts.conf

All of the parameters are fairly self-explanatory. Refer to the ypldapd(8) manpage and the ypldapd user's manual for complete information on the directives you can use in the configuration file.

Depending on how you have configured access control for the entries in your directory, you may need to assign ypldapd a privileged DN to use when it binds to the LDAP server, as it needs to view all user information (i.e., the userPassword attribute value). Otherwise, ypldapd uses an anonymous bind, and may therefore be unable to access certain attributes or entries. Here's how to set up a privileged DN:

## Define a DN used for binding to the LDAP server.
binddn uid=ypldapproxy,ou=people,dc=plainjoe,dc=org
      
## Include the clear-text password for the binddn.
bindcred secret

This configuration assumes that a user named ypldapproxy exists in the directory, and that the following access control rule is defined in slapd.conf. Because of OpenLDAP's "first match wins" algorithm for processing access control rules, this definition should be listed before any others.

## Give the ypldapproxy user read access to all information. 
access to dn=".*,dc=plainjoe,dc=org" 
     by dn="uid=ypldapproxy,ou=people,dc=plainjoe,dc=org" read

However, this configuration allows users to view passwords for all accounts using the ypcat(1) or ypmatch(1) commands. To prevent users from accessing passwords, the hide_password parameter instructs ypldapd to implement shadow passwords:

## Hide the password field from nonprivileged users.
hide_passwords on

Once ypldapd is running, you should be able to test the server using the various yp* commands. For example:

# ypwhich
192.168.1.77
      
# ypmatch gcarter passwd.byname
gcarter:##gcarter:780:100:G Carter:/home/gcarter:/bin/bash