Directory Information

The information held in the directory consists of entries and alias entries, which is the information base, and of infrastructure information, which determines how the information base is structured.

Directory Entries

A directory entry is a set of attributes and their values. Every entry has an object class attribute, which specifies the kind of object the entry describes, and defines the set of attributes it contains. Some attributes are mandatory and some are optional. The schema defines the attributes that are mandatory and optional for an entry of a given object class.

Directory information is hierarchical, with entries organized in a tree structure. Each entry has a parent entry and can have child entries. The top of the hierarchy is known as the root entry.

An entry is identified by its distinguished name (DN). A distinguished name is a sequence of attributes and values. The first attribute is the naming attribute of the entry. This attribute and its value provide the entry's relative distinguished name (RDN). The rest of the sequence is the distinguished name of the parent entry. A distinguished name is unique throughout the whole directory service.

FIGURE 4-1 shows an example of how directory information is structured, with the DNs and RDNs of the shaded entries.

FIGURE  4-1 Directory Information Structure

The directory information is divided into naming contexts. A naming context is a subtree of the directory, and is identified by the DN of the entry at the top of the naming context. A naming context is stored in a data store. A data store can hold more than one naming context.

In a general-purpose directory, you have to decide what information you want to store, and how that information will be organized. The SIMS directory service has already been designed for you, though you can modify this design, as described in "Modifying the Schema."

Aliasing

You can define an alias entry. An alias entry is identified by a distinguished name. It contains the name of the directory entry it represents (the aliased object name) and the naming attribute of the alias entry. The alias entry and the entry it represents must be in the same data store.

For bind and search operations, you can specify that the directory should translate an alias DN to the DN of the actual entry. This is known as dereferencing the alias. For other operations, you need to treat the alias entry as an ordinary entry and not dereference it, for example, to modify the RDN of the alias entry itself, not of the aliased object.

Alias Entries and Searching

The result of a search or read operation involving an alias entry differs depending on whether or not you dereference the alias. For example, suppose your directory contains the following pair of entries:

cn=Stan Smith, role=Personnel Administrator, ou=Personnel, ou=Corporate, o=XYZ, c=US
with attributes:	objectclass=orgPerson
	cn=Stan Smith
	telephoneNumber=123 456 7890
	mail=dtmail
cn=personnel, o=XYZ, c=US
with attributes:	objectclass=alias
	cn=personnel
	aliasedObjectName="cn=Stan Smith, role=Personnel Administrator, ou=Personnel, ou=Corporate, o=XYZ, c=US"

There are four possible settings for the alias dereference flag:

Never dereference alias-All operations apply to the entry with the given DN, even though the entry is an alias entry. This is the default setting.

Dereference alias when finding base object-The base object identifies the top of the subtree of entries to be searched. This setting means that if you specify an alias as the base object it will be dereferenced, but no other aliases encountered during the search are dereferenced.

Dereference alias when searching-If the operation being carried out is a search, all alias entries specified or used in the search are dereferenced. If the result of the search is an alias entry, the aliased object is returned to the user, not the alias entry. This can sometime lead to unexpected results to searches based on DN content, where the requested information is not present in the entries returned, because the entry that contains the requested DN term is an alias entry that has been dereferenced.

Always dereference alias-All alias entries specified or used in the operation are dereferenced.

For example, with alias dereferencing when searching, if you search for the telephone number of cn=Personnel Administrator, o=XYZ, c=US, you will see Stan Smith's telephone number. With no alias dereferencing, you would not see a telephone number.

Defining aliases for roles is particularly useful when the person occupying a role changes frequently (the duty network manager for out-of-hours calls, for example), so that users always query the same entry. You can change the value of the aliasedObjectName with a script that runs on a schedule and calls ldapmodify to make the changes.

See "ldapsearch" for details of how to specify how alias dereferencing is used in ldapsearch.

Alias Entries and Authentication

Every interaction with the directory starts with a bind request, to authenticate the user and establish the level of access permitted. The DN supplied in a bind request can be the DN of an alias entry. With alias dereferencing, the user binds with the DN contained in the aliasedObjectName of the alias entry, and is granted the access rights defined for the entry with that DN.

If aliases are not being dereferenced, the user binds with the DN of the alias entry and is refused access because the password attribute is not present.

Infrastructure Information

Infrastructure information determines how the components of a directory service behave and how directory entry information is interpreted. It includes the directory schema, knowledge information, and component configuration information.