Creating the Directory Tree Structure

Decide whether to use a flat or a hierarchical tree structure. As a general rule, try to make the directory tree as flat as possible. However, a certain amount of hierarchy can be important later when information is partitioned across multiple databases, prepare replication, and set access controls.

The structure of the tree involves the following steps and considerations: Section 4.2.2.1, “Branching the Directory”

Section 4.2.2.2, “Identifying Branch Points” Section 4.2.2.3, “Replication Considerations” Section 4.2.2.4, “Access Control Considerations” 4 .2.2.1. Branching the Directory

Design the hierarchy to avoid problematic name changes. The flatter a namespace is, the less likely the names are to change. The likelihood of a name changing is roughly proportional to the number of components in the name that can potentially change. The more hierarchical the directory tree, the more components in the names, and the more likely the names are to change.

Following are some guidelines for designing the directory tree hierarchy:

Branch the tree to represent only the largest organizational subdivisions in the enterprise. Any such branch points should be limited to divisions (such as Corporate Information Services, Customer Support, Sales and Professional Services, and Engineering). Make sure that the divisions used to branch the directory tree are stable; do not perform this kind of branching if the enterprise reorganizes frequently.

Use functional or generic names rather than actual organizational names for the branch points. Names change. While subtrees can be renamed, it can be a long and resource-intensive process for large suffixes with many children entries. Using generic names that represent the function of the organization (for example, use Engineering instead of Widget Research and

Developm ent) makes it much less likely that you will need to rename a subtree after organizational or project changes.

If there are multiple organizations that perform similar functions, try creating a single branch point for that function instead of branching based along divisional lines.

For example, even if there are multiple marketing organizations, each of which is responsible for a specific product line, create a single ou=Marketing subtree. All marketing entries then belong to that tree.

Branching in an Enterprise Environment

Name changes can be avoided if the directory tree structure is based on information that is not likely to change. For example, base the structure on types of objects in the tree rather than organizations. This helps avoid shuffling an entry between organizational units, which requires modifying the distinguished name (DN), which is an expensive operation.

There are a handful of common objects that are good to use to define the structure: ou=people

ou=groups ou=services

A directory tree organized using these objects might appear as shown below.

Figure 4 .2. Example Environment Directory Tree

Branching in a Hosting Environment

For a hosting environment, create a tree that contains two entries of the object class organization (o) and one entry of the object class organizationalUnit (ou) beneath the root suffix. For example, Example ISP branches their directory as shown below.

Figure 4 .3. Example Hosting Directory Tree

4 .2.2.2. Identifying Branch Points

When planning the branches in the directory tree, decide what attributes to use to identify the branch points. Remember that a DN is a unique string composed of attribute-data pairs. For example, the DN of an entry for Barbara Jensen, an employee of Example Corp., is

uid=bjensen,ou=people,dc=exam ple,dc=com.

Each attribute-data pair represents a branch point in the directory tree, as shown in Figure 4.4, “The Directory Tree for Example Corp.” for the directory tree for the enterprise Example Corp.

Figure 4 .4 . The Directory Tree for Example Corp.

Figure 4.5, “Directory Tree for Example ISP” shows the directory tree for Example ISP, an Internet host.

Figure 4 .5. Directory Tree for Example ISP

Beneath the suffix entry c=US,o=exam ple, the tree is split into three branches. The ISP branch

contains customer data and internal information for Example ISP. The internet branch is the domain tree. The groups branch contains information about the administrative groups.

Consider the following when choosing attributes for the branch points: Be consistent.

Some LDAP client applications may be confused if the distinguished name (DN) format is inconsistent across the directory tree. That is, if l is subordinate to ou in one part of the directory tree, then make sure l is subordinate to ou in all other parts of the directory service.

Try to use only the traditional attributes (shown in Section 4.2.2.2, “Identifying Branch Points”). Using traditional attributes increases the likelihood of retaining compatibility with third-party LDAP

client applications. Using the traditional attributes also means that they are known to the default directory schema, which makes it easier to build entries for the branch DN.

Table 4 .1. Traditional DN Branch Point Attributes

Attribute Name Definition

dc An element of the domain name, such as

dc=exam ple; this is frequently specified in pairs, or even longer, depending on the domain, such as dc=exam ple,dc=com or

dc=m tv,dc=exam ple,dc=com.

c A country name.

o 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, as in Section 4.2.1.1, “Suffix Naming Conventions”.

ou An organizational unit. This attribute is typically

used to represent a smaller divisional branching of the enterprise than an organization.

Organizational units are generally subordinate to the preceding organization.

st A state or province name.

l or locality A locality, such as a city, country, office, or facility name.

NOTE

A common mistake is to assume that the directory is searched based on the attributes used in the distinguished name. The distinguished name is only a unique identifier for the directory entry and cannot be used as a search key. Instead, search for entries based on the attribute-data pairs stored on the entry itself. Thus, if the distinguished name of an entry is

uid=bjensen,ou=People,dc=exam ple,dc=com, then a search for dc=exam ple does not match that entry unless dc:exam ple has explicitly been added as an attribute in that entry.

4 .2.2.3. Replication Considerations

During the directory tree design process, consider which entries are being replicated. A natural way to describe a set of entries to be replicated is to specify the DN at the top of a subtree and replicate all entries below it. This subtree also corresponds to a database, a directory partition containing a portion of the directory data.

For example, in an enterprise environment, one method is to organize the directory tree so that it corresponds to the network names in the enterprise. Network names tend not to change, so the directory tree structure is stable. Further, using network names to create the top level branches of the directory tree is useful when using replication to tie together different Directory Servers.

For instance, Example Corp. has three primary networks known as flightdeck.exam ple.com, tickets.exam ple.com, and hangar.exam ple.com. They initially branch their directory tree into three main groups for their major organizational divisions.

Figure 4 .6. Initial Branching of the Directory Tree for Example Corp.

After creating the initial structure of the tree, they create additional branches that show the breakdown of each organizational group.

Figure 4 .7. Extended Branching for Example Corp.

The Example ISP branches their directory in an asymmetrical tree that mirrors their organization.

Figure 4 .8. Directory Branching for Example ISP

After creating the initial structure of their directory tree, they create additional branches for logical subgroups.

Figure 4 .9. Extended Branching for Example ISP

Both the enterprise and the hosting organization design their data hierarchies based on information that is not likely to change often.

4 .2.2.4 . Access Control Considerations

Introducing a hierarchy into the directory tree can be used to enable certain types of access control. As with replication, it is easier to group similar entries and then administer them from a single branch. It is also possible to enable the distribution of administration through a hierarchical directory tree. For example, to give an administrator from the marketing department access to the marketing entries and an administrator from the sales department access to the sales entries, design the directory tree according to those divisions.

Access controls can be based on the directory content rather than the directory tree. The filtered

mechanism can define a single access control rule stating that a directory entry has access to all entries containing a particular attribute value. For example, set an ACI filter that gives the sales administrator access to all the entries containing the attribute value ou=Sales.

However, ACI filters can be difficult to manage. Decide which method of access control is best suited to the directory: organizational branching in the directory tree hierarchy, ACI filters, or a combination of the two.