Chapter 8. Directory design examples

PDF

The design of the directory service depends on the size and nature of the enterprise. The following examples are a starting point for developing a real-life directory service deployment plan.

8.1. Local enterprise design example

A small company ExampleCom is an automobile parts manufacturer and has 500 employees. ExampleCom decides to deploy Red Hat Directory Server to support the directory-enabled applications it uses.

8.1.1. Data design of the local enterprise

To decide which type of data the directory will store, ExampleCom creates a deployment team that performs a site survey. The deployment team determines the following key points:

A messaging server, a web server, a calendar server, a human resources application, and a white pages application will use the directory.
The messaging server performs exact searches on attributes such as uid, mailServerName, and mailAddress. To improve database performance, ExampleCom will maintain indexes for these attributes.
For more information about using indexes, see Using indexes to improve database performance.
The white pages application searches for user names and phone numbers. Therefore, the directory must handle lots of frequent substring, wildcard, and fuzzy searches that return large sets of results. The ExampleCom company decides to maintain the following indexes:
- The presence, equality, approximate, and substring indexes for the cn, sn, and givenName attributes.
- The presence, equality, and substring indexes for the telephoneNumber attribute.
The directory must maintain user and group information to support an LDAP server-based intranet deployed in the organization. A directory administrator group will manage most of the ExampleCom user and group information. However, ExampleCom wants a separate group of mail administrators to manage the email information.
The directory must store user public key certificates to support public key infrastructure (PKI) applications, such as S/MIME email.

8.1.2. Schema design of the local enterprise

Applications that the ExampleCom directory supports require the userCertificate and uid (userID) attributes. Therefore, the ExampleCom deployment team decides to use the inetOrgPerson object class to represent the entries in the directory because it allows both attributes.

In addition, ExampleCom wants to customize the default directory schema by creating the examplePerson object class to represent employees. This object class is derived from the inetOrgPerson object class. examplePerson allows one exampleID attribute. This attribute contains the special employee number assigned to each employee. In the future, ExampleCom can add new attributes to the examplePerson object class.

8.1.3. Directory tree design of the local enterprise

Based on the prepared data and schema design, the ExampleCom creates the following directory tree:

Figure 8.1. Directory tree of ExampleCom

The root of the directory tree is dc=example,dc=com, which is the company Internet domain name.
The directory tree has four branch points:
- ou=people
- ou=groups
- ou=resources
- ou=roles
All ExampleCom 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 a distinguished name (DN) for each entry. For example, the company contains entries for Babs Jensen (uid=bjensen) and Emily Stanton (uid=estanton).
For each department in ExampleCom, the sales, marketing, and accounting roles are created.
Each person entry contains a role attribute that identifies the department to which the person belongs. The company can now create access control instructions (ACIs) based on these roles.
For more information about roles, see Section 4.3.2, “About roles in Directory Server”
The following group branches are created under the ou=groups branch:
- The cn=administrators group contains entries for the directory administrators that manage the directory contents.
- The cn=messaging admins group contains entries for the mail administrators that manage only mail accounts. This group corresponds to the administrator group that the messaging server uses.
The following branches under the ou=resources branch are created:
- The ou=conference rooms branch for conference rooms.
- The ou=offices branch for offices.
A class of service (CoS) is created that provides values for the mailquota attribute depending on whether an entry belongs to the administrative group. This CoS provides administrators with a mail quota of 100GB, while ordinary ExampleCom employees have a mail quota of 5GB.

8.1.4. Topology design of the local enterprise

The ExampleCom deployment team starts to design the directory database and server topologies.

ExamleCom designs the following database topology:

Figure 8.2. Local enterprise database topology

Database 1 stores the ou=people branch.
Database 2 stores the ou=groups branch.
Database 3 stores the ou=resources and ou=roles branches and the dc=example,dc=com root suffix.

ExamleCom designs the following server topology:

Figure 8.3. Local enterprise server topology

ExampleCom decides to have the server topology with two supplier servers and three consumer servers. Each of the two suppliers updates all three consumers in the deployment of Directory Server.

The consumers supply data to one messaging server and the other servers. 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 that is responsible for the main copy of the data being modified.

8.1.5. Replication design of the local enterprise

ExampleCom decides to use a multi-supplier replication design to ensure the high availability of its directory data. For more information about multi-supplier replication, see Multi-supplier replication.

Multi-supplier architecture

ExampleCom uses two supplier servers in a multi-supplier replication architecture. The suppliers update one another so that the directory data remains consistent. The following diagram shows the supplier-supplier architecture for ExampleCom.

Figure 8.4. ExampleCom multi-supplier architecture

Supplier-consumer architecture

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

Figure 8.5. ExampleCom supplier-consumer architecture

Both supplier servers update the three consumer servers. This ensures that the consumers will not be affected if one of the supplier servers fails.

8.1.6. Local enterprise security design

To protect the directory data, ExampleCom creates the following access control instructions (ACIs):

An ACI that allows employees to modify their entries. Users can modify all attributes except the uid, manager and department attributes.
An ACI that allows only the employee and employee manager to see the employee home address and phone number to protect the privacy of employee data.
An ACI at the root of the directory tree that grants 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 allowed by these object classes, including the mail attribute. ExampleCom also grants the messaging administrators group the write, delete, and add permissions to the group subdirectory to create mail groups.
A general ACI at the root of the directory tree that allows anonymous access for the read, search, and compare access. In addition, this ACI denies anonymous users access to the password information.
An ACI that gives members of the accounting role access to all payroll information.

In addition, ExampleCom decides on the following security measures:

To protect the server from denial of service attacks and inappropriate use, ExampleCom sets resource limits based on the DN used by directory clients to bind:
- Anonymous users can receive 100 entries at a time in response to search requests.
- Messaging administrators can receive 1,000 entries.
- Directory administrators can receive the unlimited number of entries.
ExampleCom creates a password policy where passwords must be at least eight characters long and expire after 90 days.
For more information about password policies, see Designing a password policy.

8.1.7. Operations decisions of the local enterprise

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.
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 indicate searches that could be indexed.

Additional resources

Log files reference.

8.2. Multinational enterprise design example

ExampleCom, previously a small company from the Local enterprise design example, has grown into a larger organization distributed across three geographic locations: USA, Europe, and Asia. The company now has more than 20,000 employees and all employees live and work in the countries where the ExampleCom offices are located.

ExampleCom 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.

When designing a directory tree for an international company, ExampleCom needs to find the solution to the following questions:

How to collect directory entries logically?
How to support data management?
How to support replication on a global scale?

In addition, ExampleCom wants to create an extranet that suppliers and trading partners can use and implement this extranet as an extension of the company intranet to external clients.

8.2.1. Data design for the multinational enterprise

ExampleCom International creates a deployment team to perform a site survey. The deployment team determines the following key points from the site survey:

A messaging server is used to provide email routing, delivery, and reading services for most of ExampleCom sites. An enterprise server provides document publishing services. All servers run on Red Hat Directory Server 12.
ExampleCom International needs to allow administrators to manage data locally. For example, the European site is responsible for managing the Europe branch of the directory and for the main copy of this branch data.
Because of the geographic distribution of ExampleCom International offices, users and applications must access the directory 24 hours a day.
Data values for certain data elements must be in several languages.
Note
All data use the UTF-8 character set. Any other character set violates LDAP standards.

In addition, the data design of the extranet must ensure that the following conditions are fulfilled:

Parts suppliers need to log in to the ExampleCom International directory to manage their contracts with the company. Parts suppliers depend on data elements used for authentication, such as name and user password.
Trading partners will use the directory to look up contact details of people in the partner network, such as email addresses and phone numbers.

8.2.2. Schema design for the multinational enterprise

ExampleCom International uses its original schema design and adds two new object classes to support the extranet:

The exampleSupplier object class allows the exampleSupplierID attribute. This attribute contains the unique ID that ExampleCom International assigns to each automobile parts supplier.
The examplePartner object class allows the examplePartnerID attribute. This attribute contains the unique ID that ExampleCom International assigns to each trade partner.

For information about customizing the default directory schema, see Customization of schema.

8.2.3. Directory tree design for the multinational enterprise

ExampleCom International creates the following directory tree:

Figure 8.6. Basic directory tree of ExampleCom International

The dc=com suffix is the root of the directory tree. Under this suffix, the company creates the following branches:

The dc=exampleCom,dc=com branch that contains internal data of ExampleCom International.
The dc=exampleNet,dc=com branch that contains data for the extranet.

The directory tree for the intranet under dc=exampleCom,dc=com has three main branches. Each branch corresponds to one of the regions where ExampleCom International has offices. These branches are identified by using the l (locality) attribute.

Under the dc=exampleNet,dc=com branch, ExampleCom International creates the following branches:

The o=suppliers branch for suppliers the company works with.
The o=partners branch for trading partners.
The ou=groups branch that contains entries for the administrators of the extranet and for mailing lists that partners subscribe to for up-to-date information on automobile parts manufacturing.

8.2.3.1. Intranet design of ExampleCom International

Each branch under dc=exampleCom,dc=com repeats the original directory tree design of ExampleCom from the Directory tree design of the local enterprise example.

Figure 8.7. Directory tree example for intranet

Under each locality, ExampleCom International creates the following branch points:

ou=people
ou=groups
ou=roles
ou=resources

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

dn: l=Asia,dc=exampleCom,dc=com
objectclass: top
objectclass: locality
l: Asia
description: includes all sites in Asia

8.2.3.2. Extranet design of ExampleCom International

The following diagram shows the directory tree for ExampleCom extranet:

Figure 8.8. Directory tree example for extranet

8.2.4. Topology design for the multinational enterprise

The ExampleCom International deployment team starts to design the directory database and server topologies.

8.2.4.1. Database topology for ExampleCom International

ExampleCom International uses the same topology design for all its localities. However, the Europe locality stores the main copies of the data for the following branches:

The dc=com root entry
The intranet under dc=exampleCom,dc=com
The extranet under dc=exampleNet,dc=com

The following diagram shows the database topology for locality Europe:

Figure 8.9. Database topology for ExampleCom Europe

The l=Europe database stores the main copy of the dc=exampleCom,dc=com and dc=com entries.

Database link 1 and Database link 2 point to databases stored locally in each country. For example, operation requests that ExampleCom Europe server receives for the data under the l=USA branch are chained by a database link to a database on a server in the USA. For more information about database links and chaining, see Using chaining.

The Europe servers contain the main copy of the data for the extranet. The extranet data is stored in three databases the following way:

Database 1 stores the main copy of the o=suppliers branch.
Database 2 stores the main copy of the o=partners branch.
Database 3 stores the main copy of the ou=groups branch.

The following diagram shows the database topology for the extranet:

Figure 8.10. Database topology for ExampleCom International Extranet

8.2.4.2. Server topology for ExampleCom International

ExampleCom International develops the following types of server topologies:

A topology for the corporate intranet. ExampleCom decides to have three data centers, one for each major locality: Europe, the USA, and Asia. Each data center contains the following servers:
- two supplier servers.
- two hub servers.
- three consumer servers.
A topology for the partner extranet.

The following diagram shows architecture of ExampleCom Europe data center:

Figure 8.11. Server topology for ExampleCom Europe

The Europe data center contains the main copy of the ExampleCom extranet. This data is replicated to two consumer servers in the USA data center and two consumer servers in the Asia data center. Overall, ExampleCom requires ten servers to support the extranet.

The following diagram shows the server architecture of ExampleCom extranet in the Europe data center:

Figure 8.12. Server topology for ExampleCom International extranet

The hub servers replicate the data to two consumer servers of each data center: Europe, the USA, and Asia.

8.2.5. Replication design for the multinational enterprise

ExampleCom International considers the following points when designing replication for its directory:

Data is managed locally.
The quality of network connections varies from site to site.
Database links are used to connect data on remote servers.
Hub servers that contain read-only copies of the data are used to replicate data to consumer servers.

The hub servers are located near important directory-enabled applications, such as a mail server or a web server.

To let supplier servers focus on write operations, only hub servers perform replication.

In the future, when ExampleCom expands and needs to add more consumer servers, the additional consumers do not affect the performance of the supplier servers.

Multi-supplier architecture

For the ExampleCom intranet, each locality stores the main copy of its data and uses database links to chain to the data in other localities.

For the main copy of its data, each locality uses a multi-supplier replication architecture.

The following diagram shows the multi-supplier architecture for the locality Europe that includes the dc=exampleCom,dc=com and dc=com branches:

Figure 8.13. Multi-supplier architecture for ExampleCom Europe

Each locality contains two suppliers that share main copies of the data for that site. Each locality is responsible for the main copy of its data.

Using a multi-supplier architecture ensures the availability of the data and helps to balance the workload managed by each supplier server.

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

The following diagram shows the interaction between two supplier servers in Europe and two supplier servers in the USA:

Figure 8.14. Multi-supplier architecture for ExampleCom Europe and ExampleCom USA

The same relationship exists between ExampleCom USA and ExampleCom Asia and between ExampleCom Europe and ExampleCom Asia.

8.2.6. Security design for the multinational enterprise

ExampleCom International uses its previous security design adding the following access controls to support its new multinational intranet:

ExampleCom adds general ACIs to the root of the intranet creating more restrictive ACIs in each country and the branches beneath each country.
ExampleCom decides to use macro ACIs to minimize the number of ACIs in the directory.
ExampleCom 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 that the LDAP operation targets. If a match occurs, Directory Server replaces the macro with the value of the DN of the targeted resource.

For more information about macro ACIs, see Using macro access control instructions.

ExampleCom adds the following access controls to support its extranet:

ExampleCom decides to use certificate-based authentication for all extranet activities. When logging in to the extranet, users need a digital certificate. The directory stores the certificates. Therefore, users can send encrypted emails by looking up public keys stored in the directory.
ExampleCom creates an ACI that forbids anonymous access to the extranet. This protects the extranet from denial-of-service attacks.
ExampleCom wants updates to the directory data to come only from an ExampleCom-hosted application. This means that partners and suppliers that use the extranet can only use the tools provided by ExampleCom. By restricting extranet users to ExampleCom preferred tools, ExampleCom administrators can use the audit logs to track the usage of the directory and limit the types of problems that can be introduced by extranet users outside of ExampleCom International.