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.
To implement either solution—an NIS/LDAP gateway server or LDAP-enabled client lookups—we 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.
More About NIS
Before discussing these strategies for replacing NIS with LDAP, it's worth understanding something about the beast we're trying to replace.[3] NIS is most commonly used to distribute system password and account maps (i.e., /etc/passwd and /etc/shadow) to client machines. It's also used to distribute the information from many other system files, such as /etc/hosts, /etc/services, /etc/group, and /etc/networks. It can also distribute a number of files that control the automatic mounting of remote file systems; and with the appropriate wizardry in sed and awk or Perl, it can be coerced into distributing almost any kind of data that can be represented in a text file.
In the NIS world, the master copy of any shared data resides on a master server, which distributes the data to slave servers. Clients, which are organized into NIS domains (not to be confused with DNS domains), can then access this information from any NIS server, master or slave, that services their domain. The NIS master acts as a directory system agent (DSA) that provides information to clients, which use this information to perform tasks such as authenticating users (i.e., the passwd map) and locating other hosts on the network (i.e., the hosts map).
The NIS information model is also characterized by a flat namespace. To use the passwd.byname map as an example (this map represents the /etc/passwd file, indexed by username), there can be only one login name of jerry. To work around this deficiency, NIS groups client machines into NIS domains, each with its own set of maps (i.e., its own set of virtual administrative files). So, two users with the login name jerry can coexist if they can be placed in different domains; for all practical purposes, different NIS domains are different directories (even though they may be served by the same server).
In contrast, LDAP allows you to create a hierarchical namespace to manage these users. Let's assume that we'll use the RDN of a node as its login name. LDAP can then maintain multiple users with the same login name if we make sure that each user belongs to a different parent node (see Figure 6-2).
Figure 6-2. Comparing namespaces in NIS and LDAP
One basic rule of system administration is that users should not notice any loss of service when you implement changes. A user does not need to be aware of where their account information is stored. It makes little difference to them, as long as they can access necessary network services. If a change results in a downgrade of service for users (no matter how big of a win for the system administrators), you'll almost certainly be forced to rip it out and go back to the old system; eventually, you'll get tired of answering all the help desk calls. Fortunately, the flexibility of the PAM and NSS interfaces can do a lot to insulate users from a change in information location.
* * *
[1] NIS was superseded by NIS+, which was never widely adopted. Describing how to replace NIS+ is beyond the scope of this book.
[2] More information on the LGPL license can be found at http://www.fsf.org/licenses/licenses.html#LGPL.
[3] This discussion is necessarily very brief. If you need more information about NIS, see Managing NFS and NIS, by Hal Stern, Mike Eisler, and Ricardo Labiaga (O'Reilly).
Schemas for Information Services
RFC 2307, "An Approach for Using LDAP as a Network Information Service," which has recently been updated in an Internet-Draft by the LDAPbis working group, defines the attribute types and object classes needed to use an LDAP directory as a replacement for NIS. Despite its experimental status, several vendors such as Sun, Apple, HP, SGI, OpenLDAP, and PADL Software have developed products that support this schema.
RFC 2307 relates directly to information stored in standard NIS maps and how these maps should be viewed by directory-enabled client applications. The list of attribute types and object classes is lengthy; for a complete description of all that is available, refer to the RFC. I will use portions of the RFC 2307 schema in examples later in this chapter. Before trying to implement these examples or experimenting with this schema on your own, consult your directory server's documentation to find out the server's level of support for RFC 2307 and the exact syntax you should use for working with RFC 2307 objects.
The first example shows how to migrate all user accounts and groups into your OpenLDAP server. While there is nothing out of the ordinary about the configuration parameters with which you'll implement this solution, here's a complete listing of the revised slapd.conf; note that two new schema files are included, nis.schema (the RFC 2307 schema) and cosine.schema (which defines items required by nis.schema):
## slapd.conf for implementing an LDAP-based Network Information Service
## Standard OpenLDAP basic attribute types and object classes
include /usr/local/etc/openldap/schema/core.schema
## cosine.schema is a prerequesite of nis.schema.
include /usr/local/etc/openldap/schema/cosine.schema
## rfc2307 attribute types and object classes
include /usr/local/etc/openldap/schema/nis.schema
## Misc. configure options
pidfile /var/run/slapd.pid
argsfile /usr/run/slapd.args
loglevel 256
## SSL configure options
TLSCipherSuite 3DES:RC4:EXPORT40
TLSCertificateFile /usr/local/etc/openldap/slapd-cert.pem
TLSCertificateKeyFile /usr/local/etc/openldap/slapd-private-key.pem
#######################################################
## Define the beginning of example database.
database bdb
suffix "dc=plainjoe,dc=org"
## Define a root DN for superuser privileges.
rootdn "cn=Manager,dc=plainjoe,dc=org"
rootpw {SSHA}2aksIaicAvwc+DhCrXUFlhgWsbBJPLxy
## Directory containing the database files
directory /var/ldap/plainjoe.org
mode 0600
## Create the necessary indexes.
index objectClass eq
## These indexes are included to support calls such as getpwuid( ), getpwnam( ), and
## getgrgid( ).
index cn,uid eq
index uidNumber eq
&n
bsp; index gidNumber eq
Figure 6-3 illustrates the relationships between the posixAccount object class and a standard entry from a Unix password file. There are two attributes, cn and description, that do not directly correspond to a field in the /etc/passwd file. The RFC 2307 posixAccount object is meant to represent a POSIX account, which doesn't map exactly to the traditional Unix password file.[4] Unix password files have the so-called GECOS field, which has historically been used to store all sorts of information: the user's full name, office number, phone number, and other things that are useful but not used directly by the operating system.[5] The cn attribute ensures that the user's full name (or common name) is present in a posixAccount entry, and the description attribute can be used to store other supplementary information.
Figure 6-3. Relationship between the posixAccount object class and passwd file entry
Figure 6-4 illustrates a similar mapping between the posixGroup object class and an entry from the /etc/group file, which NIS represents using the group.byname map.
Figure 6-4. Relationship between the posixGroup object class and group file entry
* * *
[4] The Portable Operating System Interface (POSIX) is a specification originally developed by the IEEE to standardize operating system interface programmers. It has since been revised to include topics such as shells, utilities, and system administration.
[5] For some interesting trivia behind GECOS (pronounced /jee' kohs/), refer to http://www.jargon.net/jargonfile/g/GCOS.html.
Information Migration
While some organizations may have the resources (such as undergraduate work study students) to re-enter the data held in the NIS maps to the LDAP store, luckily, there are other means available. In addition to the PAM and NSS LDAP reference modules available at PADL Software's web site, you'll also find a set of Perl scripts designed to convert the various /etc system files (e.g., /etc/passwd and /etc/hosts) into LDIF format. Once you've converted the system files to LDIF, you can import them into your LDAP store either online using the ldapadd(1) command or by using an offline database creation utility such as the OpenLDAP slapadd(8c) tool. These LDAP migration scripts can be found at http://www.padl.com/OSS/MigrationTools.html.
After unpacking the migration scripts, you must customize the migrate_common.ph script to fit your network settings. Within this Perl script is a variable named $DEFAULT_BASE , which is used to define the base suffix under which the organizational units that will serve as containers for migrated information will be created.
The scripts accept input and output filenames as command-line parameters. If no output filename is present, the scripts write the converted entries to standard output. For example, the following command converts /etc/passwd into an LDIF file:
root# migrate_passwd.pl /etc/passwd /tmp/passwd.ldif
Here's what a typical entry from /etc/passwd looks like after it has been translated:
dn: uid=gcarter,ou=people,dc=plainjoe,dc=org
uid: gcarter
cn: Gerald Carter
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}LnMJ/n2rQsR.c
shadowLastChange: 11108
shadowMax: 99999
shadowWarning: 7
shadowFlag: 134539460
loginShell: /bin/bash
uidNumber: 780
gidNumber: 100
homeDirectory: /home/gcarter
gecos: Gerald Carter
All the required fields (cn, uid, uidNumber , gidNumber, and homeDirectory) defined in the RFC schema for a posixAccount are present. There are also a number of shadow fields (shadowLastChange, etc.; see the shadowAccount object in Figure 6-5), which hold values related to password aging. These values are taken automatically from the /etc/shadow file. If your system doesn't use shadow passwords, the shadowAccount object class values may not be present.
Figure 6-5. Relationship between the shadowAccount object class and /etc/shadow file entry
Different scripts exist to translate each system file into LDIF records. The information in each file is stored in a different organizational unit directly beneath the base suffix (defined in migrate_common.ph) in the directory. Each ou listed next is used by convention. The nss_ldap library can be configured to pull information from other locations, as we will see later. Currently, the migration scripts support translating:
/etc/fstab (stored in ou=Mounts)
/etc/hosts (stored in ou=Hosts)
/etc/passwd and /etc/shadow (stored in ou=People)
/etc/group (stored in ou=Group)
/etc/protocols (stored in ou=Protocols)
/etc/rpc (stored in ou=Rpc)
/etc/services (stored in ou=Services)
/etc/networks (stored in ou=Networks)
netgroups (stored in ou=Netgroups)
In each case, the PADL migration scripts do not create the top-level organization unit for you. Make sure that these exist prior to attempting to generate LDIF files in the directory. Since we are primarily dealing with users and groups in this chapter, the following entries have already been added to the directory:
dn: ou=people,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: people
dn: ou=group,dc=plainjoe,dc=org
objectclass: organizationalUnit
ou: group
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_ldap.html. 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.
* * *
Warning
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
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.
Table 6-1. ldap.conf parameters shared by pam_ldap and nss_ldap
Parameter
Description
host
The IP address (or hostname) of the LDAP server. The value must be resolvable without LDAP support. If a host is not specified, the nss_ldap library will attempt to locate an LDAP server by querying DNS
for an SRV record for _ldap._tcp.
base
The base DN to use in searches.
ldap_version
The version of LDAP to use when querying the server. Legal values are 2 and 3. Version 3 is used by default if it is supported by the client libraries.
binddn
The DN to use when binding to the LDAP server. This is an optional parameter; it is necessary when access control on directory entries prohibits anonymous searches.
bindpw
The password used when binding to the LDAP server (if the binddn was defined).
port
The port to use when contacting the LDAP server. The default is port 389. Also refer to the uri parameter.
rootbinddn
This parameter allows you to map the effective UID 0 (i.e., the root UID) to a DN that is used to bind to the LDAP server. If enabled, the password for this DN is read from /etc/ldap.secret. This follows the convention that the root account should be able to access all information on the system.
ssl
This parameter defines the behavior of the PAM and NSS modules for negotiating SSL when binding to the server. By default, SSL is not used. The client can be configured to use LDAPS by setting this parameter to on, or to use the StartTLS Extended command by setting this parameter to start_tls.
LDAP System Administration Page 14
