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

• A Multinational Enterprise and its Extranet

An Enterprise

---

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

• "Data Design"

• "Schema Design"

• "Directory Tree Design"

• "Topology Design"

• "Replication Design"

• "Security Design"

• "Tuning and Optimizations"

• "Operations Decisions"

Data Design

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

• Siroe's directory will be used by iPlanet Messaging Server, iPlanet Web Server, iPlanet Calendar Server, a human resources application, and a white pages application.

• iPlanet Messaging Server does exact searches on attributes such as the uid, mailServerName, and mailAddress attributes. To improve database performance, Siroe will maintain indexes for these attributes to support searches by iPlanet Messaging Server.

  For more information on using indexes refer to "Using Indexes to Improve Database Performance".

• The white pages application will frequently search for user names and phone numbers. The directory will therefore need to be able to handle lots of substring, wildcard, and sounds-like searches which return large sets of results. Siroe decides to maintain approximate and substring indexes for the dn, sn, and givenName attributes

• Siroe's directory maintains user and group information to support an iPlanet server-based intranet deployed throughout the organization. Most of Siroe's user and group information will be centrally managed by a group of directory administrators. However, Siroe also wants email information to be managed by a separate group of mail administrators.

• Siroe plans to support public key infrastructure (PKI) applications in the future, such as s/mime email, so needs to be prepared to store the public key certificates of users in the directory.

Schema Design

Siroe'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 Siroe's directory.

Siroe also wants to customize the default directory schema. Siroe creates the siroePerson object class to represent employees of Siroe Corporation. It derives this object class from the inetOrgPerson object class.

The siroePerson object class allows one attribute, the siroeID attribute. This attribute contains the special employee number assigned to each Siroe employee.

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

Directory Tree Design

Siroe creates a directory tree as follows:

• The root of the directory tree is Siroe's internet domain name: dc=siroe,dc=com.

• The directory tree has four branch points: ou=people, ou=groups, ou=roles and ou=resources.

• All of Siroe's people entries are created under the ou=people branch.

  The people entries are all members of the person, organizationalPerson, inetOrgPerson, and siroePerson object classes. The uid attribute uniquely identifies each entry's DN. For example, Siroe contains entries for Babs Jensen (uid=bjensen) and Emily Stanton (uid=estanton).

• Siroe creates three roles, one for each department in Siroe: sales, marketing, and accounting.

  Each person entry contains a role attribute which identifies the department to which the person belongs. Siroe can now create ACIs based upon these roles.

  For more information about roles, refer to "About Roles".

• Two group branches are created under the ou=groups branch.

  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 iPlanet Messaging Server. Siroe makes sure that the group it configures for Messaging Server is different from the group it creates for Directory Server.

• Two branches are created under the ou=resources branch, one for conference rooms (ou=conference rooms) and one for offices (ou=offices).

• Siroe creates a class of service (CoS) that provides values for the mailquota attribute depending upon whether or not an entry belongs to the administrative group.

  This CoS gives administrators a mail quota of 500 MB while ordinary Siroe employees have a mail quota of 100 MB.

  For more information about CoS, refer to "About Class of Service".

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

Figure 8-1    Directory Tree for Siroe Corporation

Topology Design

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

Database Topology

Siroe 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 Siroe's directory looks as follows:

Figure 8-2    Database Topology for Siroe Corporation

Server Topology

Each of the two supplier servers updates all three consumer servers in Siroe's deployment of directory server. These consumers supply data to one iPlanet Messaging Server and to the other Unified User Management products using iPlanet Data Access Router (iDAR).

For more information about the iPlanet Unified User Management products, refer to http://www.iplanet.com/products/.

The Siroe server topology follows:

Figure 8-3    Server Topology for Siroe Corporation

Modify requests from the iPlanet servers (such as the Calendar Server or the Delegated Admin Server) are routed by iDAR 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

Siroe 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 99.

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

Supplier Architecture

Siroe 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 Siroe Corporation

Supplier Consumer Architecture

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

Figure 8-5    Supplier/Consumer Architecture for Siroe 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

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

• Siroe creates 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, Siroe develops an ACI that allows only the employee and an employee's manager to see the employee's home address and phone number.

• Siroe creates an ACI that allows the two administrator groups the appropriate directory permissions is created at the root of the directory tree.

  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, the attributes contained on those object classes, as well as the mail attribute. Siroe also grants the messaging administrators group write, delete, and add permissions to the group subdirectory for creation of mail groups.

• A general access control is created on the root of the directory tree that allows anonymous access for read, search, and compare access.

  This ACI denies anonymous users access to password information.

• To protect the server from denial of service attacks and inappropriate use, Siroe sets resource limits based on the DN used by directory clients to bind.

  Siroe allows anonymous users to receive 100 entries at a time in response to search requests, administrator 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 "User Account Management" in the iPlanet Directory Server Administrator's Guide.

• Siroe creates a password policy where passwords must be at least 8 characters in length and expire after 90 days.

  For more information about password policies, refer to "Designing a Password Policy".

• Siroe creates an ACI that gives members of the accounting role access to all payroll information.

Tuning and Optimizations

Siroe optimizes its deployment of directory by doing the following:

• Running the idsktune utility

  The idsktune utility provides an easy and reliable way of checking the patch levels and kernel parameter settings for your system. For more information about idsktune, see the iPlanet Directory Server Installation Guide.

• Optimizing the entry and database caches

  Siroe 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

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

• Back up the databases every night and write the backups to tape once a week.

• Use SNMP to monitor the server status.

  For more information about SNMP, refer to the iPlanet Directory Server Administrator's Guide.

• Auto-rotate the access logs.

• Monitor the error log to see if 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, refer to "Monitoring Server and Database Activity" in the iPlanet Directory Server Administrator's Guide.

A Multinational Enterprise and its Extranet

---

This example builds a directory infrastructure for Siroe International. Siroe 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 Siroe Corporation, expanding the directory design to meet its new needs.

Siroe has grown into an organization dispersed over three main geographic locations: the US, Europe, and Asia. Siroe now has more than 20,000 employees, all of which live and work in the countries where the Siroe offices are located. Siroe 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 logically collect directory entries, how to support data management, and how to support replication on a global scale.

In addition, Siroe 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 Siroe International:

• "Data Design"

• "Schema Design"

• "Directory Tree Design"

• "Topology Design"

• "Replication Design"

• "Security Design"

Data Design

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

• iPlanet Messaging Server is used to provide electronic mail routing, delivery, and reading services for most of Siroe's sites. Enterprise server is used to provide document publishing services. All servers run on the Solaris UNIX operating system.

• Siroe needs to allow data to be managed locally. For example, the European site will be responsible for managing the Europe branch of the directory. This also means that Europe will be responsible for the master copy of its data.

• Because of the geographic distribution of Siroe's offices, the directory needs to be available to users and applications 24 hours a day.

• Many of the data elements need to accommodate data values of several different languages and characters sets.

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

• Suppliers will need to log in to Siroe's directory to manage their contracts with Siroe. Suppliers will depend upon data elements used for authentication, such as name and user password.

• Siroe's partners will use the directory as a way to look up the email addresses and phone number of people in the partner network.

Schema Design

Siroe builds upon its original schema design by adding schema elements to support the extranet. Siroe adds two new objects, the siroeSupplier object class and the siroePartner object class.

The siroeSupplier object class allows one attribute, the siroeSupplierID attribute. This attribute contains the unique ID assigned by Siroe International to each auto part supplier it works with.

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

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

Directory Tree Design

Siroe creates a directory tree as follows:

• The directory tree is rooted in the suffix dc=com. Under this suffix, Siroe creates two branch. One branch, dc=siroeCorp,dc=com, contains data internal to Siroe International. The other branch, dc=siroeNet,dc=com, contains data for the extranet.

• The directory tree for the intranet (under dc=siroeCorp,dc=com) has three main branches, each corresponding to one of the regions where Siroe has offices. These branches are identified using the l(locality) attribute.

• Each main branch under dc=siroeCorp,dc=com mimics the original directory tree design of Siroe Corporation. Under each locality, Siroe creates an ou=people, an ou=groups, an ou=roles, and an ou=resources branch. See "Directory Tree for Siroe Corporation" for more information about this directory tree design.

• Under the dc=siroeNet,dc=com branch, Siroe creates three branches. One branch for suppliers (o=suppliers), one branch for partners (o=partners), and one branch for groups (ou=groups).

• The ou=groups branch of the extranet contains entries for the administrators of the extranet as well as mailing lists that partners subscribe to for up-to-date information on auto part manufacturing.

The basic directory tree that results appears as follows:

Figure 8-6    Basic Directory Tree for Siroe International

The directory tree for the Siroe intranet appears as follows:

Figure 8-7    Directory Tree for Siroe International's Intranet

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

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

The directory tree for Siroe's extranet appears as follows:

Figure 8-8    Directory Tree for Siroe International's Extranet

Topology Design

Next, Siroe 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 Siroe's main localities, Europe:

Figure 8-9    Database Topology for Siroe Europe

The database links point to databases stored locally in each country. For example, operation requests received by the Siroe 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".

The master copy of the data for dc=siroeCorp,dc=com and the root entry, dc=com, is kept in the Europe, 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 figures shows the database topology for the extranet:

Figure 8-10    Database Topology for Siroe 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

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

For the intranet, Siroe 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 Siroe Europe's data center appears as follows:

Figure 8-11    Server Topology for Siroe Europe

Siroe'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, Siroe requires ten servers to support the extranet.

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

Figure 8-12    Server Topology for Siroe International's Extranet

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

Replication Design

Siroe considers the following when designing replication for its directory:

• Data will be managed locally.

• Quality of network connections varies from site to site.

• Database links will be used to connect data on remote servers.

• Hub servers that contain read-only copies of the data will be used to replicate data to consumer servers.

  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 Siroe 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 101.

Supplier Architecture

For the Siroe 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=siroeCorp,dc=com and dc=com information, appears as follows:

Figure 8-13    Supplier Architecture for Siroe 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 load of work managed by each supplier server.

To reduce the risk of total failure, Siroe Corporation uses multiple read-write master 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 Siroe Europe and Siroe US

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

Security Design

Siroe International builds upon its previous security design, adding the following access controls to support its new multinational intranet:

• Siroe adds general ACIs to the root of the intranet, creating more restrictive ACIs in each country and the branches beneath each country.

• Siroe decides to use macro ACIs to minimize the number of ACIs in the directory.

  Siroe 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 iPlanet Directory Server Administrator's Guide.

Siroe adds the following access controls to support its extranet:

• Siroe decides to use certificate-based authentication for all extranet activities. When people log in to the extranet, they need a digital certificate. The directory is used to store the certificates. Because the directory stores the certificates, users can send encrypted email by looking up public keys stored in the directory.

• Siroe creates an ACI that forbids anonymous access to the extranet. This protects the extranet from denial of service attacks.

• Siroe wants updates to the directory data to come only from a Siroe hosted application. This means that partners and suppliers using the extranet can only use the tools provided by Siroe. Restricting extranet users to Siroe's preferred tools allows Siroe administrators to use the audit logs to track the use of the directory and limits the types of problems that can be introduced by extranet users outside of Siroe International.

• Siroe will use iDAR to add additional security. For more information about iDAR, go to http://www.iplanet.com/.