eDirectory Naming Conventions

Articles and Tips: article

Kevin Burnett
Senior Research Engineer
Novell AppNotes
kburnett@novell.com

01 Oct 2002

Each object in the eDirectory tree has a name, which is determined by the value of the eDirectory schema attribute and which the object's base object class definition specifies. Currently, eDirectory has four name types that identify objects in the eDirectory tree:

Relative Distinguished Name
Name Context
Fully Qualified Distinguished Name
Partially Qualified Distinguished Name

Let's look at each of these name types in greater detail.

Relative Distinguished Name

In an eDirectory tree, each object's name is referred to as its Relative Distinguished Name or RDN. The value of the RDN is equivalent to the value of the object's naming attribute, which is determined by the object's expanded object class definition.

An object cannot be located based solely on its RDN. The object's name context is also required. (For more information about name context, see "Name Context" below.)

Objects in the eDirectory tree

Figure 1 shows that the object Bert has a base object class of User. The expanded object class definition for the object class User specifies that the schema attribute CN (Common Name) is to be used as the naming attribute.

For this particular object, the value for the CN is Bert; therefore the RDN for this object is Bert.

Name Context

Each object in the eDirectory tree exists in a specific name context. The name context is determined by the object's location in the hierarchical tree structure and is composed of container object names.

The name context is obtained by combining the names of the object's parent objects (superior objects) into one reference. The ordering of the object names in the name context is determined by the naming syntax chosen. The name context does not include the name of the eDirectory tree, the RDN of the [Root] object, or the RDNs of noncontainer objects.

For example, Figure 2 shows the following:

The User object Bert is subordinate to the Container object GroupWise.
The Container object GroupWise is subordinate to the Container object Support.
The Container object Support is subordinate to the Container object San Diego.
The Container object San Diego is subordinate to the Container object of ACME_CORP.

By combining the container names in the order described above, you can form the context for Bert, which is GroupWise.Testing.San Diego.ACME_ CORP.

Subordination in eDirectory

Fully Qualified Distinguished Name

The Fully Qualified Distinguished Name (FqDN) is the only naming type that can fully identify an object anywhere in the eDirectory tree. An object's FqDN is determined by combining the object's RDN with the object's name context. The dot naming syntax requires a period to precede an FqDN. When a user enters an FqDN, the eDirectory client is instructed to disregard the object's current name context.

Note: FqDN is the naming type most commonly used by eDirectory clients.

Figure 3 and 4 shows two leaf objects with Relative Distinguished Names of Bert. While these objects have the same RDN, they exist in different name contexts. One object exists in the name context of Client.Support.San Diego.ACME_CORP, while the other exists in the name context of GroupWise.Testing.San Diego. ACME_CORP.

Leaf object with Relative Distinguished Names of Bert

Each object in the eDirectory tree must have a unique FqDN, regardless of its base object class. Objects in different name contexts may have the same RDN; however, objects in the same name context must have unique RDNs.

Conclusion

This month we have discussed some of the naming conventions available in eDirectory. Next month we will continue with the naming conventions discussion.

* Originally published in Novell AppNotes

Disclaimer

The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.