Chapter 9 Directory Design Examples

This chapter contains the following examples of the possible ways to organize your directory tree based on the size and nature of your enterprise:

A Small Organization—This example provides a detailed example on how you should design your directory tree for a small organization with simple data needs. This section forms the basis for all other types of directory tree design.

A State Government—This example shows you how you can design your directory tree for a state government, or any other organization comprised of a loose collection of independently operating organizations.

An International Corporation—This example shows you how you can design your directory tree to support a large, multinational organization.

Enabling the Extranet—This example shows you how you should publish directory information to support the extranet.

The only purpose of this directory is to maintain user and group information in support of an Netscape server-based intranet that you are deploying through your organization. You want most of your user and group information to be centrally managed by a group of directory administrators. However, you also want email information to be managed by a separate group of mail administrators.

Finally, your organization consists of three organizational units: Engineering, Marketing, and Accounting.

Your directory tree should appear as follows:

• Root your directory tree in an Internet domain name or, if no such name is available, in the actual name of your organization. Do not root your directory tree in a country designator. Use the organization attribute (o) to root your directory. For example: o=airius.com
• Create two primary branch points in your directory tree: ou=people and ou=groups.
• Under ou=people, create all of your people entries. Use the person or inetOrgPerson object class for these entries. Also, since Netscape servers requires you to populate all user entries with a unique uid attribute value, you should use this value to uniquely identify each entry's DN.

Also for each person entry, create and populate an organizationalUnit (ou) attribute with the organization that the person belongs to (Engineering, Marketing, or Accounting).

You can, if you wish, also populate each person entry with a second organization (o) attribute that represents your directory root point, but this is strictly optional.

• In your group subdirectory, you need to create at least two groups. The first is used by your directory administrators to manage your directory contents. For example, use a group called cn=administrators, o=<your suffix>.

The second group that you need to create is used by your mail administrators to manage mail accounts. This group should correspond to the administrators group used by the messaging server's administration server. Make sure the group that you configure for the messaging server is different than the group you create for the Directory Server. For example: cn=messaging admin, ou=groups, o=<your suffix>.

• At the root point of your directory tree, create your ACIs that allow your two groups the appropriate directory permissions. Your directory administrators group needs full access to the directory. Your 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. You may also want to grant the messaging administrators group write, delete, and add permissions to the group subdirectory for creation of mail groups.
• At the root point of your directory tree, define some general access-control privileges, such as anonymous access for read, search, and compare, or authenticated read, search, and compare access. The Netscape Communicator Address Book feature requires anonymous access read, search, and compare access.

The following shows a sample directory tree designed as described above:

Also, just as an example, suppose that your LDAP directory service will participate in a global directory structure and/or you are co-existing with a legacy X.500 directory service. Also suppose you are designing your directory tree for the fictional state of Verona, and that the following agencies and municipalities are immediately interested in participating in your state-wide LDAP directory service:

• The cities of New Port and Brighton
• The state agencies of the Legislature, Department of Natural Resources (DNR), and the Department of Motor Vehicles (DMV)
• The counties of Anoka and Brighton

Then do the following:

• Use a suffix for your directory service of st=Verona, c=US
• Create the following branch points:

• o=cities, st=Verona, c=US
• o=counties, st=Verona, c=US
• o=DNR, st=Verona, c=US
• o=DMV, st=Verona, c=US
• o=Legislature, st=Verona, c=US
• Under the ou=cities branch, create the entries l=New Port, o=cities, st=Verona, c=US and l=Brighton, o=cities, st=Verona, c=US
• Under the o=counties branch, create the entries l=Brighton, o=counties, st=Verona, c=US and l=Anoka, o=counties, st=Verona, c=US.
• For each state agency, individual county, and individual city branch, treat the subtree as if it were a small organization. For an example of a small organization tree, see "A Small Organization".
• For the l=New Port, ou=cities, st=Verona, c=US entry, create a smart referral to the server and port where the New Port directory service is running. Also, on the LDAP URL specify the suffix of l=City of New Port, st=Verona, c=US. For example:

ldap://directory.newport.com/l=City of New Port, st=Verona, c=US

• whether you will support local data management
• the quality of the network connecting the various sites in your enterprise
• the nature of your directory data and your enterprise's need to replicate any piece of data everywhere
• whether all of the organizations in your enterprise can, or are willing to, share the same directory suffix (Some enterprises, such as corporations with subsidiaries, will find that a common suffix across the entire enterprise is difficult to create).

Single Suffix, Global Directory Tree Replication

Suppose you have an international organization, that you want to centrally manage all your data, and that you want all your data to be universally available. In this case, the directory tree that you would design would not be entirely different than what you would use for a small organization (see "A Small Organization".)

The only difficult part of this directory design is determining your replication strategy. This section provides an example replication strategy that will support a very large and complicated replication environment such as might be required by a multinational corporation (replication is discussed in detail in Chapter  7, "Planning Replication.")

Because multinational corporations often encompass hundreds of thousands of employees in dozens of countries, you should consider using a replication master to support this environment. Essentially, a replication master is a Directory Server whose only function is to replicate directory data to consumer servers. The replication master is the only consumer of your central supplier server. By using a replication master, you can free up your master Directory Server to handle all write activities for your enterprise.

Extremely large multinational corporations are most likely to have to support local data management to some extent. This is because different countries will require different employment information, and different sites within your enterprise will require different kinds of information depending on the activities at that site.

The best way to support his kind of an enterprise is to determine what information is needed company-wide and what is needed only locally. If possible, segregate this information into subtrees that are needed locally and subtrees that are needed globally. To aid replication, group all of the trees needed globally in an ou=global tree and then replicate that single tree. For example:

Some very large organizations will not have the luxury of using the same suffix across the entire enterprise. As in the case of a state government (see "A State Government"), some organizations may have already deployed a directory service and in the process created a suffix that is different from the suffix used by your enterprise. In other situations, you may have a corporation with one name that owns multiple subsidiaries who are known by some other name.

A slightly different but related topic is the situation in which you allow each organization to manage their own unique directory service. In this case, each organization may be using the same suffix, or even the same directory tree design, but the nature of your enterprise/directory data may be such that you do not want to replicate directory data everywhere. Yet you may want your users to be able to (infrequently) locate data owned by other organizations.

You can solve these kinds of problems by creating a directory of directories. A directory of directories is a directory tree that contains smart referrals to other Directory Servers around your enterprise.

For example, suppose you have a parent corporation (parent.com) with two subsidiaries (child1.com and child2.com). Suppose that everyone is running their own directory service and that everyone is using different suffixes. Then you can create a Directory Server that contains smart referrals to these different Directory Servers. People looking for entries in other organizations directory services can simply go to this central "directory of directories" and perform the search there. The smart referral mechanism will ensure that all search requests are routed and reformatted appropriately. In fact, the user performing the search may not ever know that the search request was referred to some other remote server.

For smaller environments, a better approach is to build the smart referrals directly into the local directory tree, as follows:

You should do the following:

1. Replicate only that set of information that you want to share with your trading partners to a Directory Server located outside your firewall. This information is likely to contain public contact information as well as private account or contract information of interest to your trading partners. You should consider this exterior Directory Server to be something of an independent directory service. As such, you should carefully plan the schema, data, and security policies that you will use for this unique service. Most likely you will find that the security policies and data management strategies that you have put into place for your internal directory service will not be appropriate for the needs of this external, more limited service.
2. On your internal directory service, create suffixes for each of your trading partner's own directory service. Each suffix should then have a corresponding root directory entry that is simply a smart referral to your trading partner's public directory service. This will allow members of your enterprise to search your internal directory service for information regarding your trading partners. All such searches will be referred to the appropriate Directory Server for handling.