JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Directory Server Enterprise Edition Deployment Planning Guide 11g Release 1 (
search filter icon
search icon

Document Information


Part I Overview of Deployment Planning for Directory Server Enterprise Edition

1.  Introduction to Deployment Planning for Directory Server Enterprise Edition

2.  Business Analysis for Directory Server Enterprise Edition

Part II Technical Requirements

3.  Usage Analysis for Directory Server Enterprise Edition

4.  Defining Data Characteristics

Determining Data Sources and Ownership

Identifying Data Sources

Determining Data Ownership

Distinguishing Between User and Configuration Data

Identifying Data From Disparate Data Sources

Designing the DIT

Choosing a Suffix

Creating the DIT Structure and Naming Entries

Branch Points and Naming Considerations

Replication Considerations

Access Control Considerations

Designing a Directory Schema

Schema Design Process

Maintaining Data Consistency

Other Directory Data Resources

5.  Defining Service Level Agreements

6.  Tuning System Characteristics and Hardware Sizing

7.  Identifying Security Requirements

8.  Identifying Administration and Monitoring Requirements

Part III Logical Design

9.  Designing a Basic Deployment

10.  Designing a Scaled Deployment

11.  Designing a Global Deployment

12.  Designing a Highly Available Deployment

Part IV Advanced Deployment Topics

13.  Using LDAP-Based Naming With Solaris

14.  Deploying a Virtual Directory

15.  Designing a Deployment With Synchronized Data


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 DIT interacts closely with other design decisions, including how you distribute, replicate, or control access to directory data.

The following sections describe the DIT 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:

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 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:

Table 4-1 Traditional DN Branch Point Attributes

Attribute Name
A country name.
An organization name. This attribute is typically used to represent a large divisional branching. The branching might include a corporate division, academic discipline, subsidiary, or other major branching within the enterprise. You should also use this attribute to represent a domain name.
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.
A state or province name.
A locality, such as a city, country, office, or facility name.
A domain component.

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 7, Directory Server Replication, in Oracle Directory Server Enterprise Edition 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.