Red Hat Training

A Red Hat training course is available for Red Hat Directory Server

Chapter 10. Directory Design Examples

The design of the directory service depends on the size and nature of the enterprise. This chapter provides a couple of examples of how a directory can be applied within a variety of different settings. These examples are a starting point for developing a real-life directory service deployment plan.

10.1. Design Example: A Local Enterprise

Example Corp., an automobile parts manufacturer, is a small company that consists of 500 employees. Example Corp. decides to deploy Red Hat Directory Server to support the directory-enabled applications it uses.

10.1.1. Local Enterprise Data Design

Example Corp. first decides the type of data it will store in the directory. To do this, Example Corp. creates a deployment team that performs a site survey to determine how the directory will be used. The deployment team determines the following:
  • Example Corp.'s directory will be used by a messaging server, a web server, a calendar server, a human resources application, and a white pages application.
  • The messaging server performs exact searches on attributes such as uid, mailServerName, and mailAddress. To improve database performance, Example Corp. will maintain indexes for these attributes to support searches by the messaging server.
    For more information on using indexes, see Section 6.4, “Using Indexes to Improve Database Performance”.
  • The white pages application frequently searches for user names and phone numbers. The directory therefore needs to be capable of frequent substring, wildcard, and fuzzy searches, which return large sets of results. Example Corp. decides to maintain presence, equality, approximate, and substring indexes for the cn, sn, and givenName attributes and presence, equality, and substring indexes for the telephoneNumber attribute.
  • Example Corp.'s directory maintains user and group information to support an LDAP server-based intranet deployed throughout the organization. Most of Example Corp.'s user and group information will be centrally managed by a group of directory administrators. However, Example Corp. also wants email information to be managed by a separate group of mail administrators.
  • Example Corp. plans to support public key infrastructure (PKI) applications in the future, such as S/MIME email, so it needs to be prepared to store users' public key certificates in the directory.

10.1.2. Local Enterprise Schema Design

Example Corp.'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 Example Corp.'s directory.
Example Corp. also wants to customize the default directory schema. Example Corp. creates the examplePerson object class to represent employees of Example Corp. 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 Example Corp. employee.
In the future, Example Corp. can add new attributes to the examplePerson object class as needed.

10.1.3. Local Enterprise Directory Tree Design

Based on the data and schema design described in the preceding sections, Example Corp. creates the following directory tree:
  • The root of the directory tree is Example Corp.'s Internet domain name: dc=example,dc=com.
  • The directory tree has four branch points: ou=people, ou=groups, ou=roles, and ou=resources.
  • All of Example Corp.'s people entries are created under the ou=people branch.
    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, Example Corp. contains entries for Babs Jensen (uid=bjensen) and Emily Stanton (uid=estanton).
  • They create three roles, one for each department in Example Corp.: sales, marketing, and accounting.
    Each person entry contains a role attribute which identifies the department to which the person belongs. Example Corp. can now create ACIs based on these roles.
    For more information about roles, see Section 4.3.2, “About Roles”.
  • They create two group branches under the ou=groups branch.
    The first group, cn=administrators, contains entries for the directory administrators, who manage the directory contents.
    The second group, cn=messaging admin, contains entries for the mail administrators, who manage mail accounts. This group corresponds to the administrators group used by the messaging server. Example Corp. ensures that the group it configures for the messaging server is different from the group it creates for Directory Server.
  • They create two branches under the ou=resources branch, one for conference rooms (ou=conference rooms) and one for offices (ou=offices).
  • They create a class of service (CoS) that provides values for the mailquota attribute depending on whether an entry belongs to the administrative group.
    This CoS gives administrators a mail quota of 100GB while ordinary Example Corp. employees have a mail quota of 5GB.
    See Section 5.3, “About Classes of Service” for more information about class of service.
The following diagram illustrates the directory tree resulting from the design steps listed above:
Directory Tree for Example Corp.

Figure 10.1. Directory Tree for Example Corp.

10.1.4. Local Enterprise Topology Design

At this point, Example Corp. needs to design its database and server topologies. The following sections describe each topology in detail.

10.1.4.1. Database Topology

The company 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). This is illustrated in Figure 10.2, “Database Topology for Example Corp.”.
Database Topology for Example Corp.

Figure 10.2. Database Topology for Example Corp.

Each of the two supplier servers updates all three consumer servers in Example Corp.'s deployment of Directory Server. These consumers supply data to one messaging server and to the other unified user management products.
Server Topology for Example Corp.

Figure 10.3. Server Topology for Example Corp.

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 data being modified.

10.1.5. Local Enterprise Replication Design

Example Corp. decides to use a multi-master replication design to ensure the high availability of its directory data. For more information about multi-master replication, see Section 7.2.2, “Multi-Master Replication”.
The following sections provide more details about the supplier server architecture and the supplier-consumer server topology.

10.1.5.1. Supplier Architecture

Example Corp. 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 for Example Corp. is described below:
Supplier Architecture for Example Corp.

Figure 10.4. Supplier Architecture for Example Corp.

10.1.5.2. Supplier Consumer Architecture

The following diagram describes how the supplier servers replicate to each consumer in the Example Corp. deployment of the directory. Each of the three consumer servers is updated by the two supplier servers. This ensures that the consumers will not be affected if there is a failure in one of the supplier servers.
Supplier and Consumer Architecture for Example Corp.

Figure 10.5. Supplier and Consumer Architecture for Example Corp.

10.1.6. Local Enterprise Security Design

Example Corp. decides on the following security design to protect its directory data:
  • They create an ACI that allows employees to modify their own entries.
    Users can modify all attributes except the uid, manager and department attributes.
  • To protect the privacy of employee data, they create an ACI that allows only the employee and their manager to see the employee's home address and phone number.
  • They create an ACI at the root of the directory tree that allows the two administrator groups the appropriate directory permissions.
    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. Example Corp. also grants the messaging administrators group write, delete, and add permissions to the group subdirectory for creation of mail groups.
  • They create a general ACI at the root of the directory tree that allows anonymous access for read, search, and compare access.
    This ACI denies anonymous write access to password information.
  • To protect the server from denial of service attacks and inappropriate use, they set resource limits based on the DN used by directory clients to bind.
    Example Corp. allows anonymous users to receive 100 entries at a time in response to search requests, messaging administrative users to receive 1,000 entries, and directory administrators to receive an unlimited number of entries.
    For more information about setting resource limits based on the bind DN, see the "User Account Management" chapter in the Red Hat Directory Server Administrator's Guide.
  • They create a password policy which specifies that passwords must be at least eight characters in length and expire after 90 days.
    For more information about password policies, see Section 9.6, “Designing a Password Policy”.
  • They create an ACI that gives members of the accounting role access to all payroll information.

10.1.7. Local Enterprise Tuning and Optimizations

The company uses the following tactics to optimize its deployment of Directory Server:
  • Running the dsktune utility.
    The dsktune utility provides an easy and reliable way of checking the patch levels and kernel parameter settings of the system. For more information about dsktune, see the Red Hat Directory Server Installation Guide.
  • Optimizing the entry and database caches.
    Example Corp. sets the entry cache size to 2GB and the database cache to 250MB to ensure that all of the indexes fit into RAM, optimizing server performance.

10.1.8. Local Enterprise Operations Decisions

The company makes the following decisions regarding the day-to-day operation of its directory:
  • Back up the databases every night.
  • Use SNMP to monitor the server status.
    For more information about SNMP, see the Red Hat Directory Server Administrator's Guide.
  • Auto-rotate the access and error logs.
  • Monitor the error log to ensure that the server is performing as expected.
  • Monitor the access log to screen for searches that should be indexed.
For more information about the access, error, and audit logs, see the "Monitoring Server and Database Activity" chapter in the Red Hat Directory Server Administrator's Guide.