Understanding the Directory Information Tree (DIT)

Directory Structure

A directory is a specialized database that is designed to retrieve information quickly and securely. It is optimized for read access because the type of information in the directory is searched often, but changes infrequently. For example, a user name that you add for a new employee is not likely to change for the entire period of employment.
Information about the services, resources, users, and other objects that are accessible from the applications is organized as a collection of individual entries that contain information about each resource. To make accessing these entries as efficient as possible, they are organized in a hierarchy called the Directory Information Tree (DIT).
The following figure shows an example of a DIT:
Directory Information Tree
The root of the tree is typically a country (C) followed by an organization (O). For example, in the preceding figure, the root of the tree is o=Alphalite Airways,c=US. One or more organizational units (OU) typically appear below the root. These are container objects in that they can contain other directory entries. Directory entries that store information about a specific resource are referred to as leaf objects and they are added to the tree under an existing container object.
The path to each entry in the tree is called its distinguished name (DN), and each DN in the tree is unique. For example, using the DIT in the preceding figure, the DN for the Airplane Maintenance Department of Alphalite Airways is ou=Planes,ou=Maintenance,o=Alphalite Airways,c=US.

Directory Entries

A directory entry contains a set of name/value pairs, which are called attributes. An objectclass attribute is required for each entry in the directory. The object class determines which attributes are allowed for the entry as well as any attributes that are required. The set of defined attributes and object classes that defines the content of acceptable entries within the directory server is called the Directory Schema.
An attribute for a given entry can have multiple values. For example, because an OU can have multiple values assigned to it, a person might belong to more than one organization unit. When the DIT is searched, the order in which the attributes are returned cannot be guaranteed. Therefore, no implicit priority or hierarchy of attribute values can exist within an entry.
Here is an example of a directory entry for a person in our example airline enterprise:
cn=John Smith,o=Alphalite Airways,c=US
cn=John Smith
cn=John_Smith
sn=Smith
objectclass=top
objectclass=person
objectclass=salesPerson
l=Chicago
title=Senior Sales Manager
ou=Finance
ou=Marketing
mail=Smith.John@alphaliteairways.com
telephonenumber=312-258-8655
roomnumber=117
uid=jsmith

Searching a Directory Information Tree

Entries in an LDAP directory can be read directly if the exact DN is known. Usually, however, the directory is searched for entries that match a particular set of specifications. In order to perform a search, the directory server has to know the starting place in the tree (called the base), how deep in the tree the user wants to look (called the scope), and the search criteria (called the filter).
The base can be any DN that is served by the directory server that is being queried. If the DN is outside the domain of the server, it might return a referral. The referral has the data that is necessary to connect to another server that might have more entries that match the filter. The client might decide either to chase (peruse possible filter matches on the other server) the referral or to ignore it.
A search can also contain a scope. The scope determines how far down in the tree from the base the search is made. A scope of BASE returns only the base object if it exists and matches the filter. (The filter is required even with a scope of BASE). A scope of ONE searches only the base and entries immediately below the base entry. A scope of SUB searches the entire sub tree starting at the base entry. Limiting the scope of a search makes it more efficient. If you know that an entry is one level below the base, then limiting the search to that scope makes the search run faster. If you want to search all entries that are below the base, search the sub tree.
A scope of BASE is used when you retrieve special entries. For example, most servers support a special entry with a DN of cn=monitor that returns information about the state of the server. When you search for that entry, a scope of BASE is required.
The search filter determines which entries below the base are returned. A simple filter consists of an attribute name, an operator, and a value. The following table describes the valid search operators.
LDAP Search Filter Operators
Operator
Definition
Description
Example
=
Equality
Attribute must exactly match value.
cn=Jean Smith
=<string>*<string>
Substrings
Substring attribute must contain substrings provided. The asterisk (*) matches zero or more characters.
(cn=*Smith, title=*Manager*)
>=
Greater than or equal to
Attribute must be greater than or equal to value.
age>=30
<=
Less than or equal to
Attribute must be less than or equal to value.
roomnumber<=3999
=*
Presence matches
Entry has attribute of specified name.
(objectclass=*)
~=
Approximate
Usually implemented as a "sounds like" algorithm. Attribute must be "approximately equal" to value.
cn~=Jean Smits
&
Boolean AND
All filters must be true.
(&(sn=Smith)(ou=Reservations))
|
Boolean OR
Any of the filters might be true.
(|(manager=cn=Jean Smith,ou=Reservations,o=Alphalite Airways,c=US)(ou=Marketing))
!
Boolean NOT
None of the filters might be true.
(&(!(ou=Maintenance)(!(ou=Finance))))