Directory Tree Design

Chapter 6
Directory Tree Design

DAP 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.

Directory Tree Overview

As is the case with many file systems, the directory tree is usually visualized as an inverted tree. The root of the tree is at the top and individual directory entries are at the lowest points on the tree. This manual refers to an entry that represents a new branch in the tree as a branch point. The following figure depicts a typical directory tree:

The root point of the tree is represented by a special entry whose distinguished name is called the directory suffix. An important part of your directory tree design will be selecting this DN. (This topic is discussed in the next section.)

Note that your directory service can include multiple directory suffixes. Each directory suffix can be considered to represent a unique tree. Existing about 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.

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.

Note that because your directory server can use multiple databases, 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

Your enterprise contains many groups that own their own data.

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:

Note that you could instead extend the directory tree so that it includes all members of the consortium, and then use smart referrals at each branch point to point to the appropriate directory server for the subtree. This method works best for tightly knit international enterprises where issues of organizational identity within the directory tree can be reduced or eliminated entirely. For enterprises that want to retain their suffix identification (this is usually purely a political and cultural issue), the use of smart referrals is the best approach

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".

Branching Your Directory Tree

Traditionally, X.500 directory services branched their directory trees to reflect organizations across the enterprise. For example, if Airius Corporation had the organizational units of Marketing, Engineering, Sales, Accounting, and Services, then the traditional directory tree would be organized as follows:

Because X.500 preceded LDAP, there is strong momentum to continue designing directory trees along these traditional organizational lines. However, you should avoid this traditional directory tree structure. Most enterprises experience significant and frequent movement of personnel between organizations. Further, some enterprises, particularly corporations, often restructure and rename their organizations with some frequency. In the end, designing your directory trees along organizational lines will only cause you significant administrative burdens when these organizational lines change.

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>

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".

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

A directory tree organized along these lines may appear as follows:

Branching to Support Replication or Referrals

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:

After your initial branching, you may want to further branch your directory tree along some of the divisions as noted in "Branching Strategies". This is especially true if each directory server is maintaining directory entries specific to that location, such as might be the case for enterprises using subtree replication and local mastering of directory data or enterprises using smart referrals to tie together different organizational entities. For example:

Branching to Support Access-Control

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:

Depending on what attributes you are basing your ACI on, it potentially helps to reduce the complexity of the search filters.
It helps to improve server performance by reducing the total number of entries to which the filter can apply.
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.

Branching to Support International Enterprises

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: