Complete Contents
Introduction
Chapter 1 Welcome to the Directory Server
Chapter 2 Directory Deployment Overview
Chapter 3 Planning Your Directory Data
Chapter 4 Planning Directory Schema
Chapter 5 Planning Security Policies
Chapter 6 Directory Tree Design
Chapter 7 Planning Replication
Chapter 8 Planning Referrals
Chapter 9 Directory Design Examples
Chapter 10 Extending Your Directory Service
Appendix A Quick Start
Previous Next Contents Index


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.


A Small Organization
Suppose your enterprise is a small organization consisting of a few hundred to a few thousand employees, or an individual division within a larger business. Also suppose that you have no plans to integrate your directory service with an X.500 directory.

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:

Remember that although this is a simple directory service that is containing relatively few entries, you should still replicate your entire directory tree at least once to ensure high availability of your directory service.

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


A State Government
If you are designing a directory tree for a state government, you most likely will want to provide room for city and county governments, for state and community colleges, and for various state and local agencies to participate in your directory tree.

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:

Also, further suppose that the city of New Port is already running their own LDAP service with a suffix of l=City of New Port, st=Verona, c=US.

Then do the following:


An International Corporation
Designing a directory tree for a global enterprise involves determining not only how to logically collect directory entries in descriptive subtrees, but also how to design the directory tree to support replication on a global scale. Exactly how you will approach this depends on a number of factors, including:

The following sections illustrate some international corporation directory designs.

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.

Beyond the use of a replication master, you need to determine which locations in your enterprise have the best network connection to other locations in your enterprise. That is, use your replication master to replicate directory data to 2-6 locations for which the replication master has a fast, reliable connection. From those consumer servers, replicate directory data to other consumer servers with which they have a good network connection. Continue this strategy until you have complete coverage across your enterprise.

Single Suffix, Local Data Management

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:

Multiple Suffixes, Local Data Management

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.

Of course, a central server will cost you some additional overhead. You will have to find the hardware resources to contain the directory service, and then the directory has to be managed. However, in extremely large enterprises with a lot of different LDAP directory services, a centralized directory of directories may be the best approach.

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

This kind of referral usage has the advantage of not forcing the user to go to a special directory service to perform cross-organization searches. The downside is that global directory tree searches will result in referrals being sent to the remote servers all the time. This will result in slower search performance and higher loads on both your network and servers. Depending on the number of users of the various directory services, the number of Directory Servers, the quality of your network connections, and the robustness of your hardware, this kind of smart referral usage may not be appropriate.


Enabling the Extranet
The extranet is a term that describes the extension of an enterprise's intranet to its trading partners. Basically, there may be a set of directory information that you might want your trading partners to access. Under these circumstances, there is also likely to be a set of information maintained by your trading partners that you want members of your enterprise to access. The question is: how to best go about doing this without violating security policies?

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.
To make this directory design work, you will have to coordinate authentication procedures with your trading partners. Every enterprise is likely to have a different approach to this problem, but the most elegant solution is probably to support certificate-based authentication for all extranet activities. For more information on using certificate-based authentication with your Directory Server, see the Netscape Directory Server Administrator's Guide.

 

© Copyright 1999 Netscape Communications Corporation