Replication

---

Like partitioning, replication design can affect the design of the directory tree. So after deciding on a replication strategy, you may need to rethink some of the decisions that you made when you first designed the directory tree. You may also need to rethink some decisions you made in partitioning. However, a word of warning: Currently there is no standard regarding replication. In all of the design phases, it is recommended that you consult the documentation shipped with the product you are using. In this step, it is absolutely required. This includes verifying that the software actually supports the features you need, e.g., multimaster replication, scheduling of replications, etc.

The goals of replication are:

• High availability: Replication of the directory increases the availability of your directory services.

• High performance: Replication places directory services as close as possible to your clients, thus enhancing performance.

• Load balancing: Distributing the entries over multiple servers prevents overloading of the server as well as the network.

• Local management: Moving the entries to the local networks where the entries are maintained reduces network traffic and enhances performance of the local directory.

Replication of the directory is called for when:

• A request is made for its partitioning

• Network traffic to the directory is too high

• Some line segments become overloaded

• Network would benefit from a backup system to guarantee availability of the directory in the event of hardware/software failures

Network Traffic to the Directory Is Too High

Even if both the hardware and the server can handle the amount of data, the traffic caused by the directory can penalize the part of the network where your directory server is installed. Depending on the access frequency of the individual parts, dividing the data over two subnetworks could help to increase network performance.

Some Line Segments Become Overloaded

If your company has a high-speed network distributed throughout the enterprise, overloaded line segments will not be an issue for you. However, not everyone is so lucky. Consider the case of an international enterprise having offices in the United States, the United Kingdom, and Germany, with each office maintaining its personnel records in a central directory. Assume that the connection between two of these nodes is not a high-speed connection or, even worse, is a dial-up connection available only a few hours a day. In such cases, it may convenient to replicate the directory and create a separate directory for each office.

Replication and Namespace

Similar to partitioning, replication design and tree design are not independent design phases. Another similarity is that you can replicate the directory only at branch points. This means that you can only move entire subtrees to new replications from the main directory. See the previous section on partitioning for more details. Note that there is a lack of standards in replication, so you have to look at your server's documentation for the unit of replication. For example, the SUN ONE directory server does not allow you to replicate a subtree because the smallest unit of replication is the database.

Security Design

Security design is an important issue in an Internet environment, but it is also important in an intranet environment. At the first glance, the reason may not be obvious. However, when you store data about persons, you assume a legal responsibility to protect that data.

Attacks against your data stores are not limited to those who are outside your enterprise. They can also be initiated from the inside. Such attacks are not necessarily the work of malign hackers. Data can also be compromised by careless users who do not have much concern about security issues. Imagine an employee who, instead of making a query against the directory to get the data needed for a commodity, just prints out everything, reads the interesting data, and throws away the output. If this printed output is recycled without being shredded, you can imagine the potential security issues.

Even if the security aspects are sufficient for the intranet, at some point you may decide to make the directory available on the extranet also. If you already have a good security design in place, you will not have to change much if you decide to make the directory visible from the outside.

When designing the security aspects of the directory, you need to decide on a strategy to protect the data stored in the directory. To do this, you need to know who can access the data and how. Again, in this step you will base your work on preceding steps. You have to know who owns the data, who maintains the data, who should be authorized to update the data, and who should be authorized to consult the directory.

Security design covers three arguments:

• Authentication: Verifies that the user is the person she claims to be. This could range from simple authentication to complicated procedures involving the use of certificates.

• Authorization: Ensures that the authenticated user can access only the data she is authorized to access

• Protection of the data: Guarantees that data traveling on the network cannot be read or modified. The level of security depends on your particular requirements. You can let all of the traffic on your network travel in clear, or you can encrypt it.

Authentication

As mentioned previously, authentication is the activity required to control who is trying to contact you. To understand which authentication scheme to put in place, you have to understand which type of data travels on the line. Therefore, you should take the information you have produced in data design and add on the sensitivity of the data. You may produce a further matrix of data mapped against the sensitivity of the data. You could use security levels as described later in the authentication scheme for your directory server implementation. A frequent classification of levels is as follows:

• Nonsecurity — otherwise classified as data in the public domain

• Data not in the public domain that requires user credentials for access (intended as DN and password)

• Sensitive data that requires user credentials plus encrypted communication

• Highly sensitive data that requires user credentials, encrypted communication, plus use of certificates

In this design phase, the implementation of the directory server you are using again comes into play. And again it may be that in this phase, you will discover that you cannot work with only one directory server. You may need to put some of the more sensitive data in a special partition, because your directory server cannot handle different security mechanisms on the same partition. For example, the implementation you are using may not allow you to use certificates for a subtree of your directory server only. Therefore, you have to put this subtree on a partition of its own. In this phase you may also be obliged to review the tree design. Otherwise, you could end up with an illegal partition.

Authorization

This is the step where you design who can do what with which data. Again you will pull out the matrix you planned at the very first step of data design. You could create a new matrix at this point that contains the data plus the corresponding access rights. At the beginning of this design phase be as restrictive as possible. If, however, you should see that some functionality that the directory server has to offer is not possible, you can relax your security restrictions a little. Once you have documented your results, you should map your configuration onto the directory server's configuration mechanism.

Protection of the Data

Until now we have protected the conversation between client and server, we have configured who can do what, and yet the most important piece may be still unprotected. We still have to protect the physical files on repository and also the configuration files. All these files have to be protected against unauthorized access. Frequently people put in complicated security mechanisms to protect the conversation between client and server, but they forget to protect physical access both to the server and to its configuration files. In order to understand your requirements, you have to understand who besides the administrators of the directory (if anyone) has access to the server the directory is installed on. Consequently, you have to protect the data and configuration files. It is, anyway, always good practice to configure a special user as owner of the directory server including the data and configuration files. Do not give to another user or group access rights to these files if not absolutely required. And again produce documentation of this step; it helps you later to understand and remember why you made this decision.

---