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

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/NISLDAPGatewayl).

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