Design of Directory Services

---

Do you remember Chapter 3, where we spoke about the models standing behind LDAP? Directory services implement these models. It is the design process that breathes reality into the concepts contained in the models. Consequently, you will find the same conceptual structure that we encountered in the models presented in Chapter 3.

Exhibit 3 puts together the activities necessary for the design of a directory. The design steps are grouped together in their corresponding model context. Exhibit 3 proposes a way to proceed in the design process, as indicated by the large gray lines. Every design step is based on the result of the previous one. Note, however, that the single design activities are not independent of each other. For example, the security design — despite being based on the outcome of the tree design — itself has an impact on the tree design. The clotted lines indicate dependencies between the individual phases in the design process.

The following subsections briefly treat each of the various design steps in the directory design process illustrated in Exhibit 3.

Data Design

This is the most important step in the design process because it deals with what the directory is all about: the data. In this step, you decide which data you will put into the directory. When designing the directory data, you will analyze a set of information about the data. The following points need to be clarified:

• Who uses the data

• Who produces the data

• Who "owns" the data

• Who should have access to the data

• The type of the data

Schema Design

The schema defines the rules to obey when putting data into the directory. It defines which data can be put into the directory and the format of that data. It also defines how comparisons should be executed in the case of queries. Take, for example, the case of phone numbers. Note that 1-800-2939-2636 and 1 800 2939 2636 are the same phone numbers in two different notations. The schema defines what a phone number looks like and when two phone numbers have to be considered as equal. In this example, the schema would define that a phone number can be divided into smaller pieces and that these pieces can be limited by hyphens or white spaces. It would furthermore specify that hyphens and space shall not be considered when making comparisons between values.

Tree Design

In this step, you lay down the logical structure of your namespace. A directory tree helps in managing large amounts of data by dividing it into smaller units that can be connected to each other in a hierarchical structure. This type of structure helps in locating data in the directory and improves performance during search functions. The decisions you make in tree design will have an enormous impact on the maintenance of the directory. The next two steps, partitioning design and replication design, can benefit from a good tree design.

Partitioning Design

Directories often hold a lot of data and, consequently, may be subjected to a heavy load of user requests. You might consider dividing the directory into smaller, more manageable pieces, with each located on a server of its own. This type of design also helps bring the data closer to the consumer. For example, assume that you have two departments, one in the United States and one in Japan. Each department has its own records. Partitioning the data would allow you to put the Japanese data onto the LAN where the Japanese users are and the U.S. data onto the U.S. LAN. Both databases would be closer to the data consumer. Furthermore, this would give you the flexibility to impose different policies for data maintenance. The requirement could also allow the use of different administrative structures or different security standards for the different partitions.

Replication Design

The same considerations that might lead you to consider partitioning as a design strategy apply also to replication. Indeed replication can he an alternative to partitioning. Replication addresses the availability of the directory in much the same way as partitioning. The objective could be to get the directory closer to the data consumer, but it could also be to increase throughput in heavily loaded machines. Replication also has the added value of keeping the directory available in the event of software or hardware failures. Replication provides a redundant data design and consequently requires mechanisms to keep the duplicated data in sync.

Security Design

In this step, you will treat a lot of issues. It involves first assuring that every user can do exactly what he is supposed to do. That means that you need to know exactly which actions which user may perform on what data. The next step is to protect the conversation between client and server in the correct way. If you set up replication or chaining, i.e., architectures that require conversations between servers, you have to protect these conversations as well. You must also think about physical security of the LDAP data configuration files. Therefore, you need to know exactly who has access to the server on which you are running your installation.

Let us now look at the various design activities in a bit more detail. As you have already noticed, these design activities are by no means independent of each other. Indeed, they are strongly interconnected. We will see these dependencies in the following sections.

As explained at the beginning of this chapter, there are a number of documents that fully describe additional procedures. At the end of this chapter, you will find a list of documents where you can find more information.

---