LDAP Overview

LDAP was designed as a consistent and standardized way to make directory data available over a network, regardless of how or where it is stored. Mac OS X Servers 10.210.4.x, Active Directory, and SunONE/iPlanet directory servers are all structured very differently. They all, however, support LDAP access to their underlying data store, and any LDAP client can query them.

So the idea behind LDAP is rather simpleit is an abstraction layer that allows for access to underlying data. The implementation of this idea, however, turns out to be rather complex. LDAP employs a hierarchical structure and odd naming convention, which tends to confuse first-time administrators. Its schema (or rules with regard to the content and format of directory data) can be extremely complex.

In general, an LDAP directory is made up of a hierarchical grouping of entries. Each entry usually contains one or more attributes; for example, a user record should have a short name, numerical user ID, and home directory path associated with it. The user record is an entry, whereas the short name and numerical user ID are attributes.

Each of these attributes has one or more values that actually contain the user data. The directory's schema ensures that particular entries have all of their required attributes, and that the format of those attributes is correct. Numerical user IDs, for instance, should always have an integer value.

The good news is that, in most cases, Apple insulates the administrator from this complexity. Particularly, in an environment where most users are on Apple computers and all are on Open Directory, you'll likely never be exposed to raw LDAP data. Integrating with other directory systems, however, can be more difficult. (Accessing eDirectory, iPlanet, or other LDAP directories will be covered later in this chapter.)

The main idea behind understanding this very complex and scalable architecture is to keep in mind that Apple maintains two attributes (and their associated prefixes) for every value. That is, every user has at least one short name as well as a long name, a user ID, and a globally unique ID. These are known as attributes, and they each have values typically associated with them. In Open Directory and OpenLDAP, these attributes have different names (Table 3.1). In Workgroup Manager, you have an option to view the Standard (Apple Open Directory) and/or native (OpenLDAP) attributes and associative values by choosing Inspector > Options (Figure 3.7).

Table 3.1. Example attribute names and values

WORKGROUP MANAGER CALLS IT....	OPEN DIRECTORY (STANDARD IN WGM) CALLS IT...	OPENLDAP (NATIVE IN WGM) CALLS IT...	TYPICAL VALUE IS...
Name	RealName	cn	Michael Stanley
User ID	UniqueID	uidnumber	2112
Short Names	RecordName	uid (NOT an error here)	msb
Login Shell	UserShell	loginShell	/bin/bash
Primary Group ID	PrimaryGroupID	gidnumber	20

Figure 3.7. Showing either Standard (Open Directory) or Native (LDAP) attribute names in Workgroup Manager's Inspector tab.

You will notice a few things. First, all three methods of naming attributes are different. Second, Open Directory attributes almost always begin with a capital letter, whereas OpenLDAP names do not. Third, what is not shown are the Apple-specific attributes, such as managed client settings. OpenLDAP has no record of these settings, so Apple has added its own schema set to the OpenLDAP architecture. These can be found by opening the /private/etc/openldap/schema/apple.schem a file. Within the scope of this book, it is not possible to handle all the potential permutations resulting from extending or modifying the schema.