Naming Model

---

In the previous section, we learned that the information model provides the basic elements to construct the directory. The naming model describes how these basic elements fit together to build up the directory. As in the information model, the LDAP naming model comprises several concepts imported from the original X.500 standard.

The naming model

• Describes how the data structures are built using the basic elements, i.e., entries and object classes.

• Makes it possible to refer unambiguously to the single entries it holds.

The naming model consists of only a few concepts. One of these concepts is the directory information tree (DIT), a treelike structure defining the namespace where the entries reside. We will have a look at the different naming models that can be used to form the DIT. Further, we will see that the distinguished name (DN) is used as an index to access the single entries in the directory. The distinguished name is not new to us. We were introduced to it in Chapter 2 when we played around with LDAP, and we encountered it again in the previous section when we discussed attributes. We will learn more about it here. We will see how to construct the DN from the relative distinguished name (RDN) and learn the relative rules. At the end we will have a brief look at the syntax used to build the distinguished name. But first we will have a closer look at the directory information tree.

The Directory Information Tree

The directory information tree (DIT) is the most important concept of the naming model. ^[2] The DIT is helpful in organizing your data and thus makes it easier to reference the data later on. It defines the structure of the directory that you build up from the single entries. Exhibit 16 shows an example of a DIT based on the example we used in our guided tour through LDAP in Chapter 2. The enterprise (o = ldap_abc.de) has a number of organizational units (ou) that hold a number of people, identified here by their user identifiers (uid). The two organizational units "Research" and "IT" have triangles under them simply to avoid repeating the "user" items of the first two organizational units. However, the triangles could also represent a further extension of the hierarchy beneath the organizational units, perhaps even located on another directory. We will learn more about this subject later, when we speak about referrals. This is only one example of a DIT; the tree could be much simpler than the one shown or much more complicated. Exhibit 17 shows an example of a much simpler, completely flat tree. Exhibit 18 shows part of a more complicated hierarchic tree. All of these examples are completely legitimate.

Exhibit 16: Example of a Directory Information Tree

Exhibit 17: Example of a Flat Directory Information Tree

Exhibit 18: Example of a More-Complicated Directory Information Tree

The layout of the directory information tree depends on a number of requirements and constraints. People normally use organizational or geographical criteria to build up the DIT, but administrative aspects could also determine the branching policy. We will learn more about this in Chapter 9, "Design of Directory Services."

LDAP provides a great deal of flexibility in the tree design, but that does not mean that everything is possible. The directory always has to be a treelike structure, i.e., every entry above the directory root has to have one ancestor. You cannot insert an entry that has no parent entry. It is not possible to construct a structure with one entry having two different ancestors as shown in Exhibit 19. This has consequences when you import a whole directory or if you add more entries. Assume you want to add a new department with new department members. Further, assume that you want to add the legal department, but instead of first adding the new department, you try to add the persons of the department first:

Exhibit 19: Example of a Not-Allowed Directory Structure

 DN: uid=user312, ou=Legal Department, o=LdapAbc.de 

The LDAP server would refuse to add this entry until you first acid the parent entry:

 DN: ou=Legal Department, o=LdapAbc.de 

The same thing can happen when you move an entry inside the tree. Consider the example in Exhibit 18, where there is a sales department in San Francisco. Let us assume you want to have one sales department for North America instead of having one sales department in every town. As we will see later in this chapter when we discuss the functional model, there is a function renaming the relative distinguished name (RDN). Now let us assume you would like to rename the sales department in San Francisco

 DN: ou=sales, ou=San Francisco, ou=California, l=North America 

by assigning a new RDN:

 RDN: ou=sales, l=North America 

What happens? This would not be possible, since now all the children of the entry with the distinguished name — DN: ou = sales, ou = San Francisco, ou = California, ou = North America — would remain without a parent, which is not allowed.

Nor could you first rename the single children of the sales entry

 RDN: uid=usrj, ou=sales, ou=San Francisco, ou=California, l=North America 

by assigning a new RDN:

 RDN: uid=usrj, ou=sales, l=North America 

Such situations are not infrequent, since reorganizations can occur in every organization for any number of reasons. The modification in the directory tree can also be much more complicated. For example, you might think it should be easy to rename the entire branch from

 RDN: l=North America 

to

 RDN: l=US 

Logically you may think that you are not really moving anything, only changing the name of one entry in the tree. However, you are actually moving the whole subtree, and every element has to be renamed from 1 = North America to 1 = US, i.e., from

 RDN: uid=usrj, ou=sales, ou=San Francisco, ou=California, l=North America 

to

 RDN: uid=usrj, ou=sales, ou=San Francisco, ou=California, l=US 

What is missing now is a solution to this problem. There is, as usual, more than one way to do this. You could first create a new entry with RDN:

 RDN: l=US 

and then copy the entries under l = US, then copy the entries under those entries, and so on until you have copied the whole subtree without the leaves. At the end, you will rename the leaves. After you have created the whole subtree, you can cancel the old one.

Another solution would simply be to export the whole directory in LDIF, modify the RDN, i.e., modify every occurrence of 1 = North America to 1 = US, and reload the LDIF again. However, this requires the directory server to be stopped and restarted, since you have to delete the old directory before reloading the new LDIF file.

The third solution to this problem could be to avoid moving the entries around the directory by creating an alias instead. We will speak about aliases later on in this chapter. For now, it is enough to know that an alias is somewhat similar to a symbolic link in the UNIX operating system. The alias resides in the directory tree not as an entry but simply as a pointer to the location of the entry.

Distinguished Name

The concept of the distinguished name is the heart of the naming model. Each entry has an attribute called "distinguished name" (DN). This attribute is used to identify the entry unambiguously. From this, it is clear that the DN must be unique throughout the whole directory. The construction of the DN is used to construct the namespace and the directory information tree.

The distinguished name is a comma-separated list of subunits called "relative distinguished names." You obtain the distinguished name in postfixing the relative distinguished name (RDN) with the distinguished name of its ancestor.

Like the DN, the RDN has to be unique. However, the RDN has to be unique only in its scope. For example, if the parent is

 DN: ou=sales, l=Europe, o=LdapAbc.org 

under this subtree there can be only one RDN:

 uid=usr1 

resulting in the DN:

 DN: uid=usr1, ou=sales, l=Europe, o=LdapAbc.org 

This means that you can have an entry with an RDN of uid = usr1 under 1 = Asia, as shown in Exhibit 18, resulting in the unique DN:

 DN: uid=usr1, ou=sales, l=Asia, o=LdapAbc.org 

There is a certain analogy to a UNIX file system. Just as the complete pathname of a file in a file system contains the complete pathname of its ancestor, the distinguished name of an entry also contains the distinguished name of its ancestor. For example if you create a new file in the directory "/home/my_directory," you choose a name that does not yet exist in this directory, otherwise you will get an error message. The same holds for the directory information tree.

Examples of Distinguished Names

To gain a better understanding of DNs, let us see just a few more examples. If you want to create a new entry under an entry with the distinguished name

 "DN: ou=IT, o=ldap_abc, c=de" 

you have to choose a name that does not yet exist in this subtree, otherwise the directory server will refuse it with an error message. "c" in this example DN stands for "country." It is one of the attributes of the object class organization. Let us suppose you add the name "Bill Palmer." The new entry would look like this:

 cn=Bill Palmer" 

resulting in a distinguished name of:

 "DN: cn=Bill Palmer, ou=IT, o=ldap_abc, c=de" 

This new name, unique inside this subtree, is called a "relative distinguished name" (RDN). In our example, the RDN is:

 "RDN: cn=Bill Palmer" 

Until now, it seemed that, as in a UNIX file system, we could use anything we found appropriate to build up the RDN. In LDAP, you must use one of the attributes of the object class that the entry implements to construct the RDN, i.e., the RDN has the following form:

 <Attribute Name>=<Attribute Value> 

You cannot use an attribute that is not part of the object class in the DN. For example, it is not possible to give an entry of type organization (objectclass: "o") a DN that contains a "dc" attribute, because the dc attribute is not part of the object class organization. Until now we did not explain the concept of domain components. You will hear more about this concept in the section entitled "Directory Suffix." However, "dc" stands for domain component. The dc attribute is contained in the object dcObject standing for domain component object. The auxiliary class dcObject can be mixed with the object class "o" to obtain DN: dc=LdapAbc,dc=de for an organization entry. For a discussion about auxiliary object classes, look back at the section "Object Class Types" found earlier in this chapter.

Relative distinguished names can also be composed of multiple attributes. The attributes then have to be concatenated by the "+" sign. Spaces around the "+" sign are ignored. If one of the attributes should contain a "+" sign, it has to be "escaped." More about this in the section entitled "Distinguished-Name Syntax." For example

 "cn=Bill Palmer + l=New York" 

would produce the distinguished name

 "cn=Bill Palmer + l=New York, ou=IT, o=ldap_abc, c=de" 

This technique is not used very often. It is sometimes used to produce unique RDNs in situations of a homonym cn, i.e., if there is a Bill Palmer in Las Vegas and another one in New York. This notation would express clearly that you mean the New York one.

The bigger the enterprise, the higher is the probability that it employs two or more "John Smith" in New York. The best solution to this problem is to use an attribute that is guaranteed to be unique throughout the whole enterprise, for example, the e-mail address. (The e-mail address is unique within the organization; otherwise it would be difficult to direct the correct mail to the correct recipient.) The user identifier (uid) in most cases should do the job as well. Another similar attribute that is widely used in most enterprises is the employeeNumber, which should be unique throughout the enterprise.

By the way, the distinguished name can also contain spaces, as evidenced by the name "Bill Palmer." Additional spaces are ignored. For example, "cn = Bill Palmer" with one space and "cn = Bill Palmer" with two spaces are equivalent. Special characters are also allowed if preceded ("escaped") by the backslash character "\". We will address this issue in greater detail in the section entitled "Distinguished Name Syntax."

Directory Suffix

All entries in the directory have a common ancestor called the "directory suffix." ^[3] In the previous example, the directory suffix was

 "o=ldap_abc, c=de" 

How should you choose the suffix? Aside from the consideration of choosing a meaningful suffix for your directory implementation, there are three styles available for use. Unlike X.500, LDAP does not force you to use a specific style to construct the directory suffix. You can use any one of the three styles. As you might imagine, the traditional X.500 naming style is an option. The other two options are the domain name system (DNS) style and the domain-component style. All directory server implementations should support these styles, but add-on software may not. Look at the documentation for the directory server and for any add-on software to see if your implementation fully supports the style you choose.

1. The traditional X.500 naming style comprises the organization name followed by the country code, as in:

    "o=ldapabc, c=de" 

2. The DNS style reflects the DNS name of your company and is generally recommended, as it allows you to fit seamlessly within the existing DNS lookup mechanism, which helps your directory clients. The same entry now looks like:

    "o=ldapabc.de" 

3. The domain component style uses the dc attribute to split your domain name into dc components. The entry now looks like:

    "dc=ldapabc, dc=de" 

We previously mentioned the dcObject class, where dcObject stands for domain component Object. The dcObject class extends the top object class by adding one required attribute: the "dc" or domain component attribute. The dcObject class is used for entries with a DN of the domain component style. For an example of an object using the dcObject class, see the preceding section entitled "Object Class Types."

Aliases

When speaking about the directory information tree (DIT), we always referred to a "treelike" structure. Now the time has come to explain how the tree structure of the DIT could be somewhat scrambled. As we have seen, there are situations where it is advantageous to avoid inserting a real entry in the DIT, instead using a placeholder pointing to the actual entry. This "placeholder" is called an "alias." An alias can therefore be seen as a construction corresponding to the symbolic link in the UNIX operating system. Those working in the Win NT or Win2000 operating systems will recognize the same object under the name "shortcut." The underlying concept is the same.

A carelessly used alias can corrupt the design of the whole directory. Aliases can point wherever you want, even to a different directory server. Because an erroneous alias can spell disaster, not all directory implementations allow the use of aliases. If your implementation does not allow aliases, you can use referrals instead of an alias. To learn more about referrals, see the next subsection or turn to Chapter 5, which discusses partitioning in some detail.

Creating an alias is easy. The procedure is the same as that used to add a new entry. The alias has a distinguished name, as do all entries. The alias, obviously, is from the object-class type "alias" and has only one required attribute, the attribute "aliasedObjectName," indicating where the real entry resides.

Referrals

As mentioned in the previous section, not all directory servers allow aliases. A referral does the same job as an alias. Let us look at referrals and how they come into play.

As directories continue to increase in size, there may come a point where it is no longer useful to hold the whole directory tree on one server. For performance reasons, we might decide to put one part of the directory tree on another directory server. However, performance is not the only reason for placing one or more parts of the directory on other servers. Administrative considerations — allowing different policies for different parts of the directory tree — might also come into play. We are not yet ready to deal with the details of partitioning or discuss the reasons for partitioning a directory. These arguments will be treated in greater detail in Chapter 5, which also covers replication. For now, we will concentrate only on referrals.

Assume that our directory server does not hold the entire directory tree and that part of the tree is located on another server. Exhibit 20 shows a possible scenario for directory partitioning. In this example, the directory tree holding the information for North America has been moved to a separate server. At this point, a client searching an entry in the sales department located at San Francisco would not find anything, receiving instead an error message indicating that the required entry had not been found on the server. This is not what we wanted to achieve. We need an entry that points to the exact location where the entry can now be found. This special entry is called a "referral."

Exhibit 20: Example of Directory Distributed on Two Servers

The referral is a special entry of the object class "referral." Like the alias, the referral has a distinguished name to locate it in the directory. The referral has one required attribute: the "ref" attribute. The ref attribute is an LDAP URL pointing to the location where the real entry can be found. Exhibit 21 shows the situation using a referral object.

Exhibit 21: Example of Directory Distributed on Two Servers with a Referral from Server 1 to Server 2

Now, when a client connects to the server and asks for information about the sales department in San Francisco, the server understands that it does not hold the information but that Server 2 should know more about it. Server 1 reports to the client that it does not hold the requested information and directs the client to Server 2. Exhibit 22 shows what happens. The client then decides if it will follow the referral or not, depending on how the client has been programmed. The various APIs available offer the application programmer tools to handle the case of a referral correctly. Referrals do not exist yet in LDAP version 2; they appear in LDAP version 3 only.

Exhibit 22: How the Client Sees a Referral

Chapter 5 provides more details about how the server handles referrals, showing also a few examples from the API programmer's point of view. Chapter 6 provides more detail about APIs for the different programming languages.

Exhibit 23 shows another way to keep two directories together, called "chaining." However, the standards do not cover chaining; it is up to the vendor implementing the LDAP protocol to determine whether chaining is supported. As seen in Exhibit 23, the client asks the server for an entry it does not hold. This time, however, the server does not respond with an instant referral. Instead, it requests the information from the server holding the information on behalf of the client. Once the original server gets the desired information, it answers the client's request.

Exhibit 23: How the Client Sees a Referral (Same as Exhibit 22) Using Chaining

Distinguished-Name Syntax

As mentioned before, additional white spaces in the distinguished names are ignored. The same holds for leading or trailing white spaces in the RDN or DN. For example "cn = Bill Palmer" with a leading space and "cn = Bill Palmer" with a trailing space are equivalent. There could be situations where the leading space may be necessary. There are also other characters that have a special meaning, for example the comma character "," used to divide the single parts of the distinguished name. Let us look at an example of the entry for "LdapAbc, Ltd." in the United Kingdom. As mentioned before, special characters have to be preceded (escaped) by the backslash "\" character:

 "o=LdapAbc\, Ltd., c=GB" 

Exhibit 24 lists the special characters that must be "escaped" for inclusion in distinguished names.

Prohibited Characters	Escape Sequence
Leading or trailing white space (<space>)	\<space>
Leading or trailing octothorp character (#)	\#
Comma (,)	\,
Plus sign (+)	\+
Equal sign ( = )	\ =
Double quote (")	\"
Backslash (\)	\\
Less than (<)	\>
Greater than (>)	\<
Semicolon (;)	\;

Exhibit 24: Prohibited Characters and Associated Escape Sequence for Use in Distinguished Names

Characters can also be represented in their hexadecimal value, prefixed with the octothorp character.

Exhibit 25 shows the exact syntax definition of a distinguished name in LDAP (v3) as defined in RTF 2253. This applies only to LDAP version 3, documented in RFC 2253. If you need more information about LDAP version 2 syntax, refer to RFC 1779. The syntax for LDAP (v2) is the same as that used for X.500 directory services. RFC 2253 is more strict than RFC 1779. The X.500 protocol and LDAP (v2) use abstract syntax notation one (ASN.1) encoding, while LDAP (v3) has chosen a UTF-8 string representation, which is human readable.

 distinguishedName = [name] ; may be empty string name = name-component *("," name-component) name-component = attributeTypeAndValue *("+" attributeType AndValue) attributeTypeAndValue = attributeType "=" attributeValue attributeType = (ALPHA 1*keychar)/oid keychar = ALPHA/DIGIT/"-" oid = 1*DIGIT *("." 1*DIGIT) attributeValue = string string     = *(stringchar/pair)              /"#" hexstring              /QUOTATION *(quotechar/pair) QUOTATION ; only from v2 quotechar  = <any character except "\" or QUOTATION > special    = ","/"="/"+"/"<"/">"/"#"/";" pair       = "\" (special/"\"/QUOTATION/hexpair) stringchar = <any character except one of special, "\" or QUOTATION > hexstring  = 1*hexpair hexpair    = hexchar hexchar hexchar    = DIGIT/"A"/"B"/"C"/"D"/"E"/"F"              /"a"/"b"/"c"/"d"/"e"/"f" ALPHA      = <any ASCII alphabetic character>                                        ; (decimal 65-90 and 97-122) DIGIT      = <any ASCII decimal digit> ; (decimal 48-57) QUOTATION  = <the ASCII double quotation mark character '"' decimal 34> 

Exhibit 25: Distinguished-Name Syntax from RFC 2253, "Lightweight Directory Access Protocol (v3)— UTF-8 String Representation of Distinguished Names"

Last but Not Least, Information about the Server

In LDAP version 3, the client can get information about the server, which provides a lot of information about itself inside the directory. This information can be queried just as normal entries are. Chapter 6 provides some practical examples of APIs, and Chapter 7 discusses the administration of a directory server. Here, we briefly review what information you can get from the server.

The server information is held in an entry called "root DSE." DSE stands for DSA Specific Entry. DSA is an abbreviation for the directory server agent. However, the entry is special because it has a DN with length zero. Let us look at the information held in the root DSE.

• LDAP version supported by the server. The client can try to obtain the LDAP version that the server supports. If the client does not successfully retrieve this information, then the user can conclude that it is LDAP version 2, which does not support this feature.

• All object classes and attribute types recognized by the server.

• The suffixes stored on the directory server. Remember that some implementations can hold more than one suffix.

• The extended operations and controls supported by the directory server. We will learn more about the extended operations and controls in the next section about the "functional model."

• Information about the supported SASL mechanisms. We will learn more about the SASL mechanisms in the final section about the "security model."

• A list of LDAP servers to consult for information that the original server could not provide.

This is only a list of information the root DSE can provide. Chapter 6, "LDAP APIs," provides examples that show how users can get this information using different programming languages.

Conclusion for Naming Model

The naming model showed you how to build a directory information tree (DIT), how the distinguished name (DN) is built up from the RDN, how the DIT depends on the DN, and what problems can arise when moving an entry inside the directory. We have also seen two methods of modifying the logic standing behind the DIT — aliases and referrals — that dynamically change the static DIT. We also reviewed the exact syntax of the distinguished name, learned how to construct the directory root, and discussed naming conventions for the directory root. Finally, we learned that the directory holds information about itself (just as it holds other information) in the form of entries.

The next section addresses the functional model. It will show you what operations the server can execute on behalf of clients with the clearance to make such requests. The final section addresses the issue of security clearances.

^[2]All the entries in the directory are organized in a tree-like structure. This structure is called DIT. The root of the DIT is also called "directory suffix." More about the directory suffix in a later section.

^[3]In the section entitled "Directory Information Tree," we learned that the DN of the root entry is called "uffix."

---