Information in a directory domain is organized by record type. Record types are specific categories of information such as users, groups, and computers. For each record type, a directory domain can contain any number of records. Each record is a collection of attributes, and each attribute has values.
If you think of each record type as a spreadsheet that contains a category of information, records are like the rows of the spreadsheet, attributes are like spreadsheet columns, and each spreadsheet cell contains values.
For example, when you define a user account by using the Server app, you’re creating a user record (a record of the “user” record type). The settings you configure for the user account—short name, full name, home folder location, and so on—become values of attributes in the user record. The user record and the values of its attributes reside in a directory domain.
In some directory services, such as LDAP and Active Directory, directory information is organized by object class. Like record types, object classes define categories of information. An object class defines similar information, named entries, by specifying attributes that an entry must or may contain.
For an object class, a directory domain can contain multiple entries, and each entry can contain multiple attributes. Some attributes have a single value, while others have multiple values. For example, the inetOrgPerson object class defines entries that contain user attributes.
The inetOrgPerson object class is a standard LDAP class defined by RFC 2798. Other standard LDAP object classes and attributes are defined by RFC 2307. Open Directory’s default object classes and attributes are based on these RFCs.
A collection of attributes and record types or object classes provides a blueprint for the information in a directory domain. This blueprint is named the schema of the directory domain. However, Open Directory uses a directory-based schema that’s different from a locally based stored schema.
Using a locally based schema configuration file can be complex. The issue with an Open Directory master that services replica servers is that if you change or add an attribute to the locally based schema of a Open Directory master, you must also make that change to each replica. Depending on the number of replicas you have, the manual update process can take an enormous amount of time.
If you don’t make the same schema change locally on each replica, your replica servers generate errors and fail when values for the newly added attribute are sent to replica servers.
To eliminate this possibility of failure, OS X uses a directory-based schema that’s stored in the directory database and is updated for each replica server from the replicated directory database. This keeps the schema for replicas synchronized and provides greater flexibility to make changes to the schema.
About the structure of LDAP entries
In an LDAP directory, entries are arranged in a hierarchical tree-like structure. In some LDAP directories, this structure is based on geographic and organizational boundaries. More commonly, the structure is based on Internet domain names.
In a simple directory organization, entries representing users, groups, computers, and other object classes are immediately below the root level of the hierarchy, as shown in the following figure:
An entry is referenced by its distinguished name (DN), which is constructed by taking the name of the entry, referred to as the relative distinguished name (RDN), and concatenating the names of its ancestor entries.
For example, the entry for Anne Johnson could have an RDN of uid=anne and a DN of uid=anne, cn=users, dc=example, dc=com.
The LDAP service retrieves data by searching the hierarchy of entries. The search can begin at any entry. The entry where the search begins is the search base.
You can designate a search base by specifying the distinguished name of an entry in the LDAP directory. For example, the search base cn=users, dc=example, dc=com specifies that the LDAP service begin searching at the entry whose cn attribute has a value of “users.”
You can also specify how much of the LDAP hierarchy to search below the search base. The search scope can include all subtrees below the search base or the first level of entries below the search base. If you use command-line tools to search an LDAP directory, you can also restrict the search scope to include only the search base entry.
