Managing Directory-Service Data

Setting up an LDAP server is just the first step in providing directory data. Next you need to populate the server with data and then modify the data on an ongoing basis. This lesson will present different methods for populating the Open Directory server.

OpenLDAP Components

slapd, located in /usr/libexec, is started at boot time by launchd and implements the OpenLDAP server daemon. It must run as the root user and will listen for incoming LDAP connections on either port 389 for unencrypted connections or port 636 for SSL-enabled connections.

As the following figure shows, a number of different command-line utilities come with OpenLDAP. These tools can be separated into two types:

• Tools that begin with slap and operate directly on the LDAP databases

• Tools that begin with ldap and go through the LDAP protocol

  

The slap tools must be run directly on the computer hosting the LDAP database. It is also advisable to shut down the LDAP server when using the slap tools or else your database may become out of sync. Keep in mind that two processesthe LDAP server itself and the slap utilitywill be writing to it at the same time.

slapcat is primarily used to generate an LDAP Interchange Format (LDIF) file from a database, which can then be added to another database by using the slapadd command. This is typically how an LDAP replica is created by hand.

Other slap commands include slapindex, which will force a reindexing of your database, and slappasswd, which can generate password hashes to be stored in the LDAP database. Since passwords are primarily stored in Password Server on Mac OS X Server, and not directly in the LDAP database, you most likely will not need slappasswd.

The ldap tools interact with the LDAP server itself and can access the server over the network. The ldap tools are the best ones for troubleshooting your LDAP server, because they replicate the interactions the LDAP server would have with a Mac OS X computer.

A common LDAP tool is ldapsearch, which can be used to query the LDAP server for a particular entry or generate an LDIF file. When you use Mac OS X to authenticate to an LDAP server, your computer will do an ldapsearch against Open Directory's LDAP server to find out your user information. For example,

ldapsearch -H ldap://127.0.0.1 -b cn=users,dc=mainserver,dc=pretendco,dc=com

will dump all records in the users container of the server's LDAP database to your Terminal window.

You can use ldapadd to load an LDIF file into your LDAP server. For example,

ldapadd -H ldap://mainserverserver.pretendco.com -f myusers.ldif

uploads the LDIF file myusers.ldif to the server once you have successfully authenticated as an administrator.

Apple LDAP Schema

The structure of the data stored in an LDAP database is defined not by the LDAP protocol but by a schema, a collection of files that define the types of records and attributes they might contain. The schema files used by Mac OS X Server are located in /etc/openldap/schema/.

The Open Directory LDAP server uses standard LDAP object classes whenever suitable. For example, accounts created with Workgroup Manager implement inetOrgPerson and posixAccount object classes. However, to support Apple-specific features, Apple has extended the schema to define auxiliary object classes so that user accounts can contain extra attributes that are not part of a defined LDAP standard. Similar object classes have been created for Apple-defined groups. These support features specific to Mac OS X:

• apple-user: Adds attributes that are part of an Apple user account but that are not supported by either the standard inetOrgPerson or posixAccount object classes. Examples include:

  • URL of the home folder

  • Home folder quotas

  • Managed client settings (MCX settings)

• apple-group: Adds attributes that are part of an Apple group but that are not supported by the posixGroup object type. Examples include:

  • URL of the group folder

  • Managed client settings

This is just a small sample of the objects and attributes Apple added. All of the added objects and attributes are defined in the file /etc/openldap/schema/apple.schema.

LDIF

An LDIF file allows you to easily add the contents of one LDAP server to another. Any server that uses the standard LDAP protocol should be able to import and export an LDIF file.

The file is in plaintext, and each entry is specified by its distinguished name. An example of the contents of an LDIF file entry is as follows:

dn: uid=froosevelt,cn=users,dc=mainserver,dc=pretendco,dc=com uid: froosevelt objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: apple-user objectClass: extensibleObject objectClass: organizationalPerson objectClass: top objectClass: person sn: 99 cn: Franklin Roosevelt uidNumber: 1025 apple-generateduid: 247E73B0-8339-11D8-B8CA-000A9585403C apple-mcxflags:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPCFET0NUW ... loginShell: /bin/bash gidNumber: 20 authAuthority: ;ApplePasswordServer;0x406b01c33b4f78190000000a0000000a,1024 35 ... 09 [e-mail]:10.1.0.1 authAuthority: ;Kerberosv5;0x406b01c33b4f78190000000a0000000a;froosevelt@SERVE ... userPassword:: KioqKioqKio= apple-user-mailattribute:: PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4 ... apple-user-homeurl:: PGhvbWVfZGlyPjx1cmw+YWZwOi8vc2VydmVyMTcucHJldGVuZGNvLmNvb ... homeDirectory: /Network/Servers/mainserver.pretendco.com/Users/froosevelt

LDAP Contacts Database

Many large organizations will put all their contact or address book information into an LDAP database. In fact, this was one of the original uses of an LDAP database. Most modern email clients, including the Apple Mail and Microsoft Entourage applications, have the ability to search for email and postal addresses over an LDAP connection.

The contact information can be located in a number of different locations. Which location your organization uses will depend on your LDAP configuration. Some administrators prefer to place contacts in the same container as the user accounts on the system. This method has the benefit of allowing users to search for both employee information and other contact information at the same time. However, mixing accounts and contacts in the same container may cause confusion when administering your users, and user accounts may contain sensitive information.

Another approach is to create an entirely new container especially for contacts. Common names for containers of this type are cn=People and cn=Contacts. This keeps the user information separate from the contact information but requires clients to either use the entire LDAP naming context as their search base or have two search entries.

A third approach, which is especially useful for organizations with a large amount of LDAP contact information, is to create an entirely separate LDAP database to hold contact information and to host it on the same computer. This "contacts" database would have a naming context unique from the other database and requires only another group of entries in the LDAP configuration files.

Workgroup Manager is a tool designed to manage account information for records specified by the Users search base in Directory Access. To edit attributes not exposed by Workgroup Manager, or if you wish to move your contact to a different container, you will have to find alternative tools to manage your contact information, such as the LDAP command-line tools discussed in the previous section.

Backing Up and Restoring Directory Data

With Server Admin, you can create an archive copy of the Open Directory master's directory and authentication data. After you select a location and click the Archive button, Server Admin creates a disk image containing the following:

• LDAP database and configuration files

• Password Server database

• Kerberos database and configuration files

• Local NetInfo database

To restore the data, enter the path to the archive image and click Restore. The data from the image will be merged with the existing master's data. If there are conflicts between the master's data and the image, the data in the master will take precedence and the conflict is recorded in the slapconfig log file.

If you have configured Open Directory replica servers to connect to Open Directory master, you will need to reconnect the replicas after restoring a server from an archive. Replica servers are covered in Lesson 10, "Replication."

Note

It is better to promote a replica to a master than to restore a master from an archive.