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

Chapter 6. Replacing NIS

One of LDAP's
chief advantages is its ability to consolidate multiple directory
services into one. This chapter examines the pros and cons of using
LDAP as a replacement for Sun's
Network Information
Service (NIS). NIS is used primarily by Unix clients to centralize
management of user information and passwords, hostnames and IP
addresses, automount maps (files that control the mounting of remote
file systems), and other administrative information. NIS clients for
other operating systems, such as Windows NT 4.0, exist, though they
aren't particularly common.^[1]

^[1] NIS was
superseded by NIS+, which was never widely adopted. Describing how to
replace NIS+ is beyond the scope of this book.

While the focus of this chapter is using an LDAP directory as a
replacement for NIS domains, many other tools are used to distribute
management information on Unix systems; for example, many sites use
rsync(1) to push administrative files, such as
/etc/passwd, to client machines. While this
chapter assumes that you are replacing NIS with an LDAP directory,
adapting these techniques I present to other schemes for sharing the
data in /etc/passwd,
/etc/hosts, and other key files should be
straightforward:

Get the information you want to share into the directory.

Get your clients to use the directory.

Disable your old information-sharing mechanism.

There are two fundamental strategies
for replacing NIS with an LDAP directory. The first solution,
illustrated in Figure 6-1, involves setting up an
NIS/LDAP gateway: i.e., an NIS server
that accepts NIS queries, but answers the queries by retrieving
information from an LDAP directory. This strategy
doesn't require any client modifications, and
therefore works with all NIS clients; it may be the easiest means of
transitioning to a new LDAP-based information service.
Sun Microsystems Directory Server 4.x
supports this approach. Sadly, newer releases (5.x) of
Sun's directory services product do not. An
alternative solution is the NIS/LDAP gateway provided by a company
named PADL
Software (http://www.padl.com/).
This gateway product is available for servers running Solaris, Linux,
FreeBSD, or AIX, and will be discussed later in this chapter.

Figure 6-1. NIS/LDAP gateway

The second solution involves making a complete transition to LDAP. If
you are willing to disable NIS lookups on all of your clients and
install the necessary LDAP libraries and modules, you may prefer this
approach. Clients access information directly from an LDAP directory,
eliminating the gateway. Many modern operating systems support
pluggable information retrieval modules; for example, Unix and
Unix-like systems such as Solaris and Linux can use the LDAP
Pluggable Authentication Modules (PAM)
and Name Server Switch (NSS) modules that
have been released by PADL Software under the GNU Lesser General
Public License (LGPL).^[2] If you are unfamiliar with PAM and NSS, read the brief
overview found in Appendix A.

^[2] More information on the LGPL
license can be found at http://www.fsf.org/licenses/licensesl#LGPL.

To implement either solutionan NIS/LDAP gateway server or
LDAP-enabled client lookupswe must define the attribute types
and object classes needed to move the information served by NIS (or
saved in static system files) into an LDAP directory.