| [ Team LiB ] |
|
6.2 Schemas for Information ServicesRFC 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
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  |
| [ Team LiB ] |
|