Chapter 6 Directory Tree Design

LDAP directory services organize directory entries using a directory tree. The design that you should use for your directory tree is determined by the types of information that you want to store in your directory service, the physical nature of your enterprise, the applications that you will use with your directory service, and the types of replication that you need to support your enterprise's activities.

In this chapter you will learn about directory trees and you will find advice on how you should design your directory tree. This chapter includes the following sections:

Directory Tree Overview—This section describes the concept of a directory tree. Also included is advice on how to plan and define your directory tree's suffix.

Branching Your Directory Tree—This section describes the branching strategies and the distinguished name designs that you should use with your directory tree.

Naming Person Entries—This section describes the distinguished name conventions that you should use for directory entries that represent people.

Naming Non-Person Entries—This section describes the distinguished name conventions that you should use for directory entries that do not represent people.

Your directory service can include multiple directory suffixes. Each directory suffix can be considered to represent a unique tree. Existing above these directory suffixes is a special entry called the Root Directory Server Specific Entry (DSE). The root DSE is a concept borrowed from X.500. The root DSE is a special entry that exists above the root entries in your directory service's various directory trees. It is represented by the null string (literally ""), and it contains attributes specific to the Directory Server instance.

Multiple Suffixes

Each suffix that you use with your directory service represents a unique directory tree. There are two ways that you can include multiple trees in your directory service. The first is to physically include the individual trees in the database(s) served by your Directory Server.

Planning Your Directory Suffix(es)

When you deploy a Netscape Directory Server, you will automatically have multiple suffixes defined for your directory. Most of these are used internally by the Directory Server and they require little or no planning on your part. These include the suffix for the machine data area, the suffix for the change log database (if configured), and the suffix for your directory schema. For more information on these standard directory trees, see the Netscape Directory Server Administrator's Guide.

Of particular importance to planning your directory tree is determining which suffix(es) you will use to store your directory data. In almost all circumstances, you should use only one suffix for data storage. However, in some specialized cases, such as for an extranet or for Internet Service Providers, multiple suffixes may be required to fully support your directory service.

In either case, the criteria for selecting a directory suffix is the same whether you will use one or 50 suffixes for your directory.

Selecting a Suffix

Traditionally LDAP directories have followed the X.500 naming convention for suffixes. This traditional form specifies an organization name followed by a country designation. For example:

o=Airius, c=US

This suffix pattern effectively roots your directory service in a specific country, which may or may not be appropriate depending on the nature of your enterprise.

The only time rooting your directory tree in a country designator is really necessary is when you are participating in an X.500 directory service. In that case, you should follow whatever DN conventions are in use by the X.500 service.

Generally, rooting your directory tree in a country designator is an acceptable practice if your enterprise is not multinational in nature. Therefore, if your enterprise is a government or military organization, educational institution, or small business, no harm can come from rooting your directory tree in a country designator. It is worth noting, however, that there is also no real benefit in doing so. Unlike X.500 directory services, LDAP does not require any specific format for the DN naming conventions, so you are free to use whatever you want for your directory suffix.

The best practice for choosing a directory suffix is to align it with a DNS name or Internet domain name associated with your enterprise. This is the best approach regardless of the nature of your enterprise. Therefore, if your enterprise owns the domain name of airius.com, then you should use a directory suffix of:

o=airius.com

Another option is to use the dc (domainComponent) attribute to represent your suffix. To represent your domain name using the dc attribute, you break your domain name into its component parts as follows:

dc=airius, dc=com

Note. If you are going to use a Netscape 1.x Certificate Server with your intranet, you should avoid the use of the dc attribute in your DNs because the 1.x certificate server does not support this attribute.

Using Multiple Suffixes: ISPs

For most directory services there is no need to use multiple suffixes with your Directory Server. The exception to this rule is Internet Service Providers (ISPs) who may be supporting multiple enterprises with their directory services. If you are an ISP, then you should approach each of your customers as a unique enterprise and design their directory trees following the advice and concerns as outlined in this book. For security reasons, each account should be provided a unique directory tree with a unique suffix and an independent security policy.

Your Directory Server can use multiple databases, so you can assign each customer their own database, and you may want place each directory tree on its own disk drive. Placing each directory tree in its own database allows you to perform backup and restore activities for each directory tree without impacting your other customer's operations.

By placing each directory tree on a unique disk drive, you reduce possible performance problems caused by disk contention, and you also reduce the number of accounts potentially impacted by a disk outage.

For more information on using backend plug-ins with your Directory Server, see the Netscape Directory Server Programmer's Guide.

Using Multiple Suffixes: Large Enterprises and Extranets

If you are supporting a very large enterprise or an extranet with your directory service, then you may want to split up the physical locations where directory data is stored and use smart referrals to locate the data. That is, place specific parts of your directory tree on individual Directory Servers, and then use smart referrals to tie the logical directory together.

There are several reasons why you may want to do this:

• Your enterprise contains many groups that own their own data.
• Your site is enabling an extranet.

An example of this may be an enterprise that includes divisions or separate business units that are responsible for managing their own personnel information and/or email systems.

Your enterprise includes sites that are geographically distant from one another. Each site may include information that is mostly important to the people at that site, but may at times be of interest to other members of the enterprise.

One such example of this may be a consortium of international consulting firms. Each firm will maintain information that only it cares about, but it may also include information (such as telephone numbers, email addresses, mailing addresses, and other contact information) that may occasionally be of interest to members of other consulting firms. The nature of this information and the frequency by which it is queried by other members of the consortium may be such that replication of this information is not warranted.

In this situation, you can assign each consulting firm its own suffix. Once each organization has an assigned suffix (again, probably based on their Internet domain identity), you can configure each Directory Server in the global enterprise to recognize each of the participating suffixes. You should then create on each server a corresponding root directory entry for each suffix. Each such root directory entry should be a smart referral to the appropriate Directory Server. For example:

Your site is enabling an extranet.

In this case, you should configure your directory service to recognize the suffix used by each of your trading partners. Again, each suffix should have a corresponding root directory entry that is a smart referral to the directory service used by that particular trading partner. For more information on enabling extranets with your directory service, see "Enabling the Extranet".

Branch Point Distinguished Name Attributes

As you decide how to branch your directory tree, you will need to decide what attributes you will use to identify the branch points. Remember that a DN is unique string composed of attribute-data pairs. Traditionally, DNs follow the format:

cn=<value>, l=<value>, ou=<value>, o=<value>, c=<value>

Netscape recommends that you change this traditional format to:

cn=<value>, l=<value>, ou=<value>, o=<domain>

The left-most attribute is called the Relative Distinguished Name (RDN). The appropriate value for the RDN is discussed in "Naming Person Entries" and "Naming Non-Person Entries".

All of the intermediate attribute-data pairs represent branch points in your directory tree. This is an area where LDAP differs from X.500. While LDAP allows you to use any attributes and attribute values for your directory branch points, X.500 identifies which attributes can appear in a DN, and even the order in which they must appear. From the LDAP perspective there is not even a requirement to use any of the traditional attributes in your DN scheme.

However, there are some things you should consider when choosing attributes to represent your branch points:

• Be consistent. Some LDAP clients (and some directory administrators for that matter) may be confused if the DN format is inconsistent across your directory tree. That is, if l is subordinate to o in one part of your directory tree, then make sure l is subordinate to o in all other parts of your directory.
• Try to use only the traditional attributes (shown in Table  6.1). While not strictly necessary, using the traditional attributes means that you have the greatest likelihood of retaining interoperability with third-party LDAP clients. Using the traditional attributes also means that they will be known to your directory schema, which is desirable when it comes time to build the entries associated with the DN.
• When creating entries, define the RDN within the entry. The RDN is the left-most DN attribute value. By defining at least the RDN within the entry, you can more easily locate the entry. Remember, you do not search against the actual DN; instead you search against the attribute values stored in the entry itself. For example, if you create a branch point called:

ou=widget research, o=airius.com

then add an ou attribute to the entry whose value is widget research.

• Attribute names have a meaning, so try to use the attribute name with the type of entry that they are representing. For example, do not use l (locality) to represent an organization, or c (country) to represent an organizational unit. The traditional attributes and their meanings are defined as follows:

Table 6.1 Traditional DN Branch Point Attributes


Attribute Name	Definition
c	Represents a country name.
o	Represents an organization name. This attribute is typically used to represent a large divisional branching such as a corporate division, academic discipline (the humanities, the sciences), subsidiary, or other major branching within the enterprise. You should also use this attribute to represent a domain name as discussed in "Selecting a Suffix".
ou	Represents an organizational unit. This attribute is typically used to represent a smaller divisional branching of your enterprise than an organization. Organizational units are generally subordinate to the preceding organization.
st	Represents a state or province name.
l	Represents a locality, such as a city, country, office, or facility name.
dc	Represents a domain component as discussed in "Selecting a Suffix".

Note. A common mistake is to assume that you search your directory based on the attributes used in the distinguished name. This is not true. The distinguished name is only a unique identifier for the directory entry, and you cannot search against it. Instead, you search for entries based on the attribute-data pairs stored on the entry itself. Thus, if your distinguished name contains the value cn=babs jensen, then you can cannot search against that attribute-data pair unless you have defined cn: babs jensen in the directory entry.

Branching Strategies

There are no performance or administrative benefits to a heavily branched directory tree. Further, when you search an LDAP directory service, you do so based on the attribute-data pairs used in the entry. You do not perform searches based on the attributes and attribute values contained in the DN itself. The sole purpose of the DN is to provide a unique name by which the entry is identified. There does not have to be any correspondence between the attributes used for the entry's DN and the attributes actually used in the entry (although you should create this correspondence when creating directory entries to help you administer your directory tree).

Because there are no performance or administrative benefits to a branched directory tree, your best approach is to keep your directory tree as flat as possible. This does not mean that you should avoid hierarchy; some benefit can exist in logically dividing your entries so that you can tell by looking at the entry's DN what type of data it holds. Some common branch points directory services are now using include:

• ou=People
• ou=Groups
• ou=Contracts
• ou=Employees
• ou=Contractors

You can organize your directory tree so that it corresponds to the network names in your enterprise. This approach is attractive because it is an extension of the strategy recommended for suffix names and because network names tend to be fairly stable entities. Further, this approach may be particularly attractive in the higher branches of your trees if your directory service is using replication or referrals to tie together different Directory Servers.

For example, if Airius has three primary networks known as flightdeck.airius.com, tickets.airius.com, and hanger.airius.com, then you might want to branch your directory tree as follows:

In some respects, the reasons why you might branch to support access-control are similar to the reasons why you might branch to support replication: it is easier to group together similar entries and then administer them from a single branch point.

However, in the case of access-control, you may have some entries to which you want to grant special privileges based on the organization to which the entries belong. That is, you may want to grant a person write privileges to entries belonging to the Marketing organization. You can, of course, branch your directory tree to include a Marketing organizational tree. However, as stated in "Branching Your Directory Tree", branches based on organizational divisions within your enterprise can lead to administrative problems when those divisional lines change.

Generally you can avoid branching for this reason by using the Netscape ACI filtered target mechanism. This mechanism allows you to apply an access-control rule to a directory entry based on some attribute-data pair included on the entry. That is, you can allow or deny access if an entry includes the attribute-data pair of:

ou: Marketing

At some point, however, you are likely to find that using search filters to support your ACL is cumbersome and difficult to manage. It is at this point that you must decide whether it is easier to branch along organizational lines, or if you would rather support a complex set of LDAP filters in your security policy.

Ultimately you will probably have to use some combination of the two mechanisms. Here are some guidelines that can make this task easier for you:

• Branch your tree to represent only the largest organizational subdivisions in your enterprise. That is, any such branch points should be limited to divisions (Corporate Information Services, Customer Support, Sales and Professional Services, and so forth). Make sure that any such divisions that you represent in your directory tree are as stable as possible; do not perform this kind of branching if your enterprise is fluid and is likely to frequently reorganize.
• Use functional or generic names rather than actual organizational names to represent your branch points. Names change and you do not want to have to change your directory tree every time your enterprise renames its divisions. Instead, use generic names that represent the function of the organization (for example, use Engineering instead of Widget Research and Development).
• If you have multiple organizations that perform similar functions, try creating a single branch point to represent that function instead of branching based along divisional lines. For example, if you have multiple marketing organizations, each of which might be responsible for a specific product line, still only create a single Marketing subtree. All marketing entries should then belong to that tree.
• Once you have created your major directory tree branches, apply your filtered-target ACIs to the branch points of the trees to which they apply. That is, if you are granting write privilege to entries belonging to Marketing Widget I, then place the ACI on the branch point to the marketing tree. This does three things for you:

1. Depending on what attributes you are basing your ACI on, it potentially helps to reduce the complexity of the search filters.
2. It helps to improve server performance by reducing the total number of entries to which the filter can apply.
3. It reduces any damage that may be caused in the event that the search filter is applied incorrectly and inappropriate entries are included in the scope of the ACI.

In "Selecting a Suffix", you are advised to avoid rooting your directory tree in a country designator. This is especially true if your enterprise is international in scope.

To support an international enterprise, you should root your directory tree in your Internet domain name, then branch your tree for each country in which your enterprise has operations immediately below that root point. Because LDAP places no restrictions on the order in which DN attributes can appear in your DNs, you can use the c (country) attribute to represent each country branch as follows:

Traditionally, distinguished names use the commonName, or cn, attribute to name their person entries. That is, an entry that represents a person named Babs Jensen might have the distinguished name of:

cn=Babs Jensen, o=Airius.com

While allowing you to instantly recognize the person represented by the entry, this format suffers in that most organizations usually include people with identical names. This quickly leads to a problem known as DN name collisions, that is, multiple entries with the same distinguished name. Remember that DNs must be unique.

One common way to avoid common name collisions is to add a unique identifier to the common name. For example:

cn=Babs Jensen 23, o=Airius.com

However, for very large directories, this can lead to awkward common names, such as:

cn=Bill Smith11022

A better approach is to identify your person entries with some attribute other than cn. There are two traditional possibilities available to you:

• uid—Use the uid (userID) attribute to specify some unique value associated with the person. Possibilities include a user login ID or an employee number.
• mail—Use the mail attribute to represent the person's email address. This option can lead to awkward DNs that include duplicate attribute values (for example: mail=bjensen@airius.com, o=airius.com), so you should use this option only if you cannot find some unique value that you can use with the uid attribute. Using the mail attribute may be appropriate if, for example, your enterprise does not assign employee numbers or user IDs for temporary or contract employees. The mail attribute in that case can be based on some email address used by the contractor on a permanent basis (for example: ssarette@hotmail.com, o=airius.com).

For these types of entries, use the commonName (cn) attribute in the RDN if possible. Therefore, if you are naming a group entry, name it as follows:

cn=administrators, o=airius.com

The caveat is if you are naming an entry whose object class does not support the commonName attribute. Since you will want to include the RDN attribute and attribute value in the directory entry to aid in locating the entry, you should use an attribute for the RDN that is supported by the entry's object class (fortunately, there are not very many object classes in the standard schema where this is a problem).

Finally, if you decide to use a non-traditional attribute for your RDN, make sure that all of the applications and clients that will use your directory support the non-standard attribute. The Netscape 1.x Certificate Server in particular has restrictions on what DNs it will support in your directory. See the Certificate Server documentation for more information.