Chapter 10. Directory Design Examples
10.1. Design Example: A Local Enterprise
10.1.1. Local Enterprise Data Design
- 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
, andmailAddress
. 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
, andgivenName
attributes and presence, equality, and substring indexes for thetelephoneNumber
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
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.
examplePerson
object class to represent employees of Example Corp. It derives this object class from the inetOrgPerson
object class.
examplePerson
object class allows one attribute, the exampleID
attribute. This attribute contains the special employee number assigned to each Example Corp. employee.
examplePerson
object class as needed.
10.1.3. Local Enterprise Directory Tree Design
- 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
,
andou=resources
. - All of Example Corp.'s people entries are created under the
ou=people
branch.The people entries are all members of theperson
,organizationalPerson
,inetOrgPerson
, andexamplePerson
object classes. Theuid
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.

Figure 10.1. Directory Tree for Example Corp.
10.1.4. Local Enterprise Topology Design
10.1.4.1. Database Topology
root suffix
information are stored in a third database (DB3). This is illustrated in Figure 10.2, “Database Topology for Example Corp.”.

Figure 10.2. Database 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
10.1.5.1. Supplier Architecture

Figure 10.4. Supplier Architecture for Example Corp.
10.1.5.2. Supplier Consumer Architecture

Figure 10.5. Supplier and Consumer Architecture for Example Corp.
10.1.6. Local Enterprise Security Design
- They create an ACI that allows employees to modify their own entries.Users can modify all attributes except the
uid
,manager
anddepartment
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
andmailGroup
object classes and the attributes contained on those object classes, as well as themail
attribute. Example Corp. also grants the messaging administrators groupwrite
,delete
, andadd
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
- Running the
dsktune
utility.Thedsktune
utility provides an easy and reliable way of checking the patch levels and kernel parameter settings of the system. For more information aboutdsktune
, 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
- 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.