Deployment Guide
Red Hat Directory Server                                                            


Chapter 8

Directory Design Examples

How you design your directory depends upon the size and nature of your enterprise. This chapter provides examples of how a directory can be applied within a variety of different settings. You can use these examples as a starting point for developing your own directory deployment plan.

This chapter contains the following example directory designs:

An Enterprise Corporation, an automobile parts manufacturer, is a small company that consists of 500 employees. decides to deploy Red Hat Directory Server (Directory Server) to support the directory-enabled applications it uses.'s directory design process involves the following steps:

Data Design first decides the type of data it will store in the directory. To do this, creates a deployment team that performs a site survey to determine how the directory will be used. The deployment team determines the following:

For more information on using indexes, see "Using Indexes to Improve Database Performance," on page 106.

Schema Design's deployment team decides to use the inetOrgPerson object class to represent the entries in the directory. This object class is appealing because it allows the userCertificate and uid(userID) attributes, both of which are needed by the applications supported by's directory. also wants to customize the default directory schema. creates the examplePerson object class to represent employees of Corporation. It derives this object class from the inetOrgPerson object class.

The examplePerson object class allows one attribute, the exampleID attribute. This attribute contains the special employee number assigned to each employee.

In the future, can add new attributes to the examplePerson object class as needed.

Directory Tree Design creates a directory tree as follows:

The people entries are all members of the person, organizationalPerson, inetOrgPerson, and examplePerson object classes. The uid attribute uniquely identifies each entry's DN. For example, contains entries for Babs Jensen (uid=bjensen) and Emily Stanton (uid=estanton).
Each person entry contains a role attribute which identifies the department to which the person belongs. can now create ACIs based upon these roles.
For more information about roles, refer to "About Roles," on page 73.
The first group, cn=administrators, contains entries for the directory administrators that manage the directory contents.
Mail administrators use the second group, cn=messaging admin, to manage mail accounts. This group corresponds to the administrators group used by the messaging server. makes sure that the group it configures for the messaging server is different from the group it creates for Directory Server.
This CoS gives administrators a mail quota of 500 MB while ordinary employees have a mail quota of 100 MB.
For more information about CoS, refer to "About Class of Service," on page 75.

The following diagram illustrates the directory tree resulting from the design steps listed above:

Figure 8-1 Directory Tree for Corporation

Topology Design

Next, designs both its database and server topologies. The following sections describe each topology in detail.

Database Topology designs a database topology in which the people branch is stored in one database (DB1), the groups branch is stored in another database (DB2), and the resources branch, roles branch, and the root suffix information are stored in a third database (DB3). The database topology for's directory looks as follows:

Figure 8-2 Database Topology for Corporation

Server Topology

Each of the two supplier servers updates all three consumer servers in's deployment of Directory Server. These consumers supply data to one messaging server and to the other Unified User Management products.

The server topology follows:

Figure 8-3 Server Topology for Corporation

Modify requests from compatible servers are routed to the appropriate consumer server. The consumer server uses smart referrals to route the request to the supplier server responsible for the master copy of the piece of data being modified.

Replication Design decides to use a multi-master replication design to ensure the high availability of its directory data. For more information about multi-master replication, refer to "Multi-Master Replication," on page 115.

The following sections provide more details about the supplier server architecture and the supplier-consumer server topology.

Supplier Architecture uses two supplier servers in a multi-master replication architecture. The suppliers update one another so that the directory data remains consistent. The supplier architecture works as follows:

Figure 8-4 Supplier Architecture for Corporation

Supplier Consumer Architecture

The following diagram describes how the supplier servers replicate to each consumer in the deployment of the directory:

Figure 8-5 Supplier/Consumer Architecture for Corporation

Each of the three consumer servers is updated by the two supplier servers as shown in Figure 8-5. This ensures that the consumers will not be affected if there is a failure in one of the supplier servers.

Security Design decides on the following security design to protect its directory data:

Users can modify all attributes except the uid, manager and department attributes.
The directory administrators group needs full access to the directory. The messaging administrators group needs write and delete access to the mailRecipient and mailGroup object classes and the attributes contained on those object classes, as well as the mail attribute. also grants the messaging administrators group write, delete, and add permissions to the group subdirectory for creation of mail groups.
This ACI denies anonymous users access to password information. allows anonymous users to receive 100 entries at a time in response to search requests, administrative users to receive 1,000 entries, and system administrators to receive an unlimited number of entries. For more information about setting resource limits based on the bind DN, refer to chapter 7, "User Account Management," in the Red Hat Directory Server Administrator's Guide.
For more information about password policies, refer to "Designing a Password Policy," on page 147.

Tuning and Optimizations optimizes its deployment of directory by doing the following:

The dsktune utility provides an easy and reliable way of checking the patch levels and kernel parameter settings for your system. For more information about dsktune, see the Red Hat Directory Server Installation Guide. sets the entry cache to 2000 entries and the database cache to 250 MB to ensure that all of the indexes fit into RAM, optimizing server performance.

Operations Decisions makes the following decisions regarding the day-to-day operation of its directory:

For more information about SNMP, refer to the Red Hat Directory Server Administrator's Guide.
For more information about the access, error, and audit logs, refer to chapter 12, "Monitoring Server and Database Activity," in the Red Hat Directory Server Administrator's Guide.

A Multinational Enterprise and Its Extranet

This example builds a directory infrastructure for International. Corporation from the previous example has grown into a large, multinational company. This example builds on the directory structure created in the last example for Corporation, expanding the directory design to meet its new needs. has grown into an organization dispersed over three main geographic locations: the US, Europe, and Asia. now has more than 20,000 employees, all of which live and work in the countries where the offices are located. decides to launch a company-wide LDAP directory to improve internal communication, to make it easier to develop and deploy web applications, and to increase security and privacy.

Designing a directory tree for an international corporation involves determining how to collect directory entries logically, how to support data management, and how to support replication on a global scale.

In addition, wants to create an extranet for use by its parts suppliers and trading partners. An extranet is an extension of an enterprise's intranet to external clients.

The following sections describe the steps in the process of deploying a multinational directory service and extranet for International:

Data Design International creates a deployment team to perform a site survey. The deployment team determines the following from the site survey:

The deployment team also determines the following about the data design of the extranet:

Schema Design builds upon its original schema design by adding schema elements to support the extranet. adds two new objects, the exampleSupplier object class and the examplePartner object class.

The exampleSupplier object class allows one attribute, the exampleSupplierID attribute. This attribute contains the unique ID assigned by International to each auto parts supplier with which it works.

The examplePartner object class allows one attribute, the examplePartnerID attribute. This attribute contains the unique ID assigned by International to each trade partner.

For information about customizing the default directory schema, refer to "Customizing the Schema," on page 48.

Directory Tree Design creates a directory tree as follows:

The basic directory tree that results appears as follows:

Figure 8-6 Basic Directory Tree for International

The directory tree for the intranet appears as follows:

Figure 8-7 Directory Tree for International's Intranet

The entry for the l=Asia entry appears in LDIF as follows:

dn: l=Asia,dc=exampleCorp,dc=com

objectclass: top

objectclass: locality

l: Asia

description: includes all sites in Asia

The directory tree for's extranet appears as follows:

Figure 8-8 Directory Tree for International's Extranet

Topology Design

Next, designs both its database and server topologies. The following sections describe each topology in more detail.

Database Topology

The following diagram illustrates the database topology of one of's main localities, Europe:

Figure 8-9 Database Topology for Europe

The database links point to databases stored locally in each country. For example, operation requests received by the Europe server for the data under the l=US branch are chained by a database link to a database on a server in Austin, Texas. For more information about database links and chaining, refer to "Using Chaining," on page 100.

The master copy of the data for dc=exampleCorp,dc=com and the root entry, dc=com, is kept in the l=Europe database, as shown by the box in Figure 8-9.

The data center in Europe contains the master copies of the data for the extranet. The extranet data is stored in three databases, one for each of the main branches. The following figure shows the database topology for the extranet.

Figure 8-10 Database Topology for International's Extranet

As illustrated in Figure 8-10, the master copy of the data for o=suppliers is stored in database one, the master copy of the data for o=partners is stored in database two, and the master copy of the data for ou=groups is stored in database three.

Server Topology develops two server topologies, one for the corporate intranet and one for the partner extranet.

For the intranet, decides to have a master database for each major locality. This means it has three data centers, each containing two supplier servers, two hub servers, and three consumer servers.

The architecture of Europe's data center appears as follows:

Figure 8-11 Server Topology for Europe's extranet data is mastered in Europe. This data is replicated to two consumer servers in the US data center and two consumer servers in the Asia data center. In all, requires ten servers to support the extranet.

The server architecture of's extranet appears as follows in the Europe data center:

Figure 8-12 Server Topology for International's Extranet

The hub servers replicate the data to two consumer servers in the Europe data center, two consumer servers in the US data center, and two consumer servers in the Asia data center.

Replication Design considers the following when designing replication for its directory:

The hub servers are located near important directory-enable applications such as a mail server or a web server.
Hub servers remove the burden of replication from the supplier servers, so the suppliers can concentrate on doing write operations. In the future, as expands and needs to add more consumer servers, the additional consumers do not affect the performance of the suppliers.
For more information about hub servers, refer to "Cascading Replication," on page 119.

Supplier Architecture

For the intranet, each locality keeps the master copy of its data and uses database links to chain to the data of other localities. For the master copy of its data, each locality uses a multi-master replication architecture. For example, the supplier architecture for Europe, which includes the dc=exampleCorp,dc=com and dc=com information, appears as follows:

Figure 8-13 Supplier Architecture for Europe

Each locality contains two suppliers, which share master copies of the data for that site. Each locality is therefore responsible for the master copy of its own data. Using a multi-master architecture ensures the availability of the data and helps balance the workload managed by each supplier server.

To reduce the risk of total failure, Corporation uses multiple read-write supplier Directory Servers at each site.

The following diagram illustrates the interaction between the two supplier servers in Europe and the two supplier servers in the US:

Figure 8-14 Supplier/Supplier Architecture for Europe and US

The same relationship as illustrated in Figure 8-14 exists between US and Asia, and between Europe and Asia.

Security Design International builds upon its previous security design, adding the following access controls to support its new multinational intranet: uses a macro to represent a DN in the target or bind rule portion of the ACI. When the directory gets an incoming LDAP operation, the ACI macros are matched against the resource targeted by the LDAP operation. If there is a match, the macro is replaced by the value of the DN of the targeted resource.
For more information about macro ACIs, refer to the Red Hat Directory Server Administrator's Guide. adds the following access controls to support its extranet:


© 2001 Sun Microsystems, Inc. Used by permission. © 2005 Red Hat, Inc. All rights reserved.
Read the Full Copyright and Third-Party Acknowledgments.

last updated May 20, 2005