Designing the DIT

DIT design involves choosing a suffix to contain your data, determining the hierarchical relationship between data entries, and naming the entries in the DIT hierarchy. The following sections describe the design process in more detail.

Choosing a Suffix

The suffix is the name of the entry at the root of the DIT. If you have two or more DITs that do not have a natural common root, you can use multiple suffixes. The default Directory Server installation contains multiple suffixes. One suffix is used to store user data. The other suffixes are for data that is needed by internal directory operations, such as configuration information and directory schema.

All directory entries must be located below a common base entry, the suffix. Each suffix name must be as follows:

• Globally unique

• Static, so that the name rarely changes

• Short, so that entries beneath the suffix are easier to read online

• Easy for a person to type and remember

It is generally considered best practice to map your enterprise domain name to a Distinguished Name (DN). For example, an enterprise with the domain name example.com would use a DN of dc=example,dc=com.

Creating the DIT Structure and Naming Entries

The structure of a DIT can be flat or hierarchical. Although a flat tree is easier to manage, a degree of hierarchy might be required for data partitioning, replication management, and access control.

Branch Points and Naming Considerations

A branch point is a point at which you define a new subdivision within the DIT. When deciding on branch points, avoid potential problematic name changes. The likelihood of a name changing is proportional to the number of components in the name that can potentially change. The more hierarchical the DIT, the more components in the names, and the more likely the names are to change.

Use the following guidelines when defining and naming branch points:

• Branch your tree to represent only the largest organizational subdivisions in your enterprise.

  Limit branch points to divisions, such as Corporate Information Services, Customer Support, Sales, and Professional Services. Make sure that your divisions are stable. Do not perform this kind of branching if your enterprise reorganizes frequently.

• Use functional or generic names rather than actual organizational names.

  Names change and you do not want to have to change your DIT 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, create a single branch point for that function instead of branching based on divisional lines.

  For example, even if you have multiple marketing organizations that are responsible for a specific product line, create a single Marketing subtree. All marketing entries then belong to that tree.

• Try to use only the traditional branch point attributes that are shown in the following table.

  Traditional attributes increase the likelihood of retaining compatibility with third-party LDAP client applications. In addition, traditional attributes are known to the default directory schema, which simplifies the construction of entries for the branch distinguished name (DN).

• Branch according to the type of data stored in the directory.

  For example, you might create a separate branch for people, groups, service, and devices.

Be consistent when choosing attributes for branch points. Some LDAP client applications might fail if the DN format is inconsistent across your DIT. If l (localityName) is subordinate to o (organizationName) in one part of your DIT, ensure that l is subordinate to o in all other parts of your directory.

Replication Considerations

When designing a DIT, consider which entries will be replicated to other servers. If you want to replicate a specific group of entries to the same set of servers, those entries should fall below a specific subtree. To describe the set of entries to be replicated, specify the DN at the top of the subtree. For more information about replicating entries, see Chapter 4, Directory Server Replication, in Sun Java System Directory Server Enterprise Edition 6.2 Reference.

Access Control Considerations

A DIT hierarchy can enable certain types of access control. As with replication, it is easier to group similar entries and to administer the entries from a single branch.

A hierarchical DIT also enables distributed administration. For example, you can use the DIT to give an administrator from the marketing department access to marketing entries, and an administrator from the sales department access to sales entries.

You can also set access controls based on directory content, rather than the DIT. Use the ACI filtered target mechanism to define a single access control rule. This rule states that a directory entry has access to all entries that contain a particular attribute value. For example, you can set an ACI filter that gives the sales administrator access to all entries that contain the attribute ou=Sales.

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