Directory Management

Consolidating information into a directory is the primary reason for implementing LDAP.

Administrative controls that allow a directory administrator to more easily manage that LDAP directory are therefore relevant to the business value LDAP provides. This type of operational functionality differs from the client-server operations I examined in Chapter 3.

This chapter addresses directory management topics. Of these topics, most are not included in the LDAP standard yet. Some of the topics are addressed by RFC documents but are not formally associated with the standard. The first half of the chapter explains advanced LDAP namespace concepts, including replication, referrals, and aliases. This discussion leads to the management issues surrounding multiple LDAP servers. Special attention is given to a distributed directory service and the effort required to integrate independent directories to centralize management.

Directory security concepts and recommendations are next, followed by some of the common server parameters and maintenance tools that you can use with LDAP.

[ Team LiB ]

[ Team LiB ]

Replication

Centralizing information into an LDAP directory raises the need for fault tolerance

Mycompany's decision to implement an LDAP directory may be stressful. Mycompany will centralize critical information into a single repository and integrate key business processes with this directory.

The implications of the central directory being unavailable are greater than when the information was in several nonintegrated directories. How can Mycompany have any peace of mind that its directory will be available if a directory server fails?

Directory replication can provide fault tolerance, but it isn't part of the LDAP standard yet

Replication is the simplest solution. With replication, you deploy more than a single directory server.

The information in the directory is then replicated between multiple directory servers, and the replicated information can be accessed from several points of distribution. However, LDAP has no specifications on how replication should be accomplished. Implementation of this feature is left to vendors. Almost every vendor does implement this feature, though. Fortunately, there is ongoing IETF discussion about what type of replication model should be used to distribute directory information from one LDAP server to another. An LDAP replication standard should emerge in the future. Mycompany will need to closely compare how each vendor implements directory replication before choosing a product.

Partitions

A partition is the portion of the directory that is replicated to other servers

A partition is the portion of the directory that is replicated to other servers. The partition is a naming context (or directory suffix) that forms the element of replication. Some vendors allow flexibility with respect to the portion of the directory that can be a partition. The directory partition is replicated (by some means chosen by the vendor) to other directory servers. Usually (but not always), the administrator has some choice of how often replication occurs and can designate which partition is replicated to which server. The term "partition" designates a unit of the directory that is being replicated. This unit is usually the same as a naming context, but it might be a smaller or larger portion of the directory.

Replicas

A replica is a replicated copy of directory information

A replica is a copy of a directory partition. The term "replica" refers to the subservient copies of the master partition. The difference between a partition and a replica is subtle. A replica is the

replicated unit of the directory.

Figure 5-1 shows examples of replication used by Mycompany. In the figure, we see part of the Mycompany directory as well as a separate directory for Mycompany's network operating system directory. The two directories have different base DNs and even different directory structures. The Accounts and Computers naming contexts of the Mycompany directory are being replicated to the NOS directory because the Mycompany directory is the primary source of information to make authoritative changes. The Accounts and Computers naming contexts (of either directory) can be referred to as partitions because they are the units of replication. You might simply call the

Accounts naming context the Accounts partition and not designate which directory or server it is on, because replication makes the content identical. Each of the Accounts partitions can also be

referred to as replicas because both directories are the destination of replication. The Computers partition of the NOS directory is also a replica. However, the Computers partition of the Mycompany

directory is not a replica, because it is not the destination of replication, but only a source.

Figure 5-1. Example of replication, partitions, and replicas

In single-master models, directory information must flow from one server; in multimaster models, there are multiple directions of flow

Some replication models suggest a single-master model, in which one directory server holds the authoritative (writable) version of any particular partition, and the other servers have this version replicated to them. In the single-master model, all modifications of data must be made on the single authoritative server and the other servers are read-only replicas. In Figure 5-1, the Computers partition is being replicated in a single-master model from the Mycompany directory to the NOS directory. In a multimaster model, all the servers hold an equally authoritative version that can each be modified. Sometimes a ring topology is used to limit the replication connections, but not always.

In Figure 5-1, the Accounts partition is being replicated in a multimaster model between both servers, so that changes can be made on either server and propagated to the other. The

multimaster model makes the replica and partition terminology much harder to distinguish, because replication is being done in multiple directions. Therefore, it shouldn't be surprising that the terms

"partition" and "replica" can frequently be used interchangeably in contexts in which they can't be distinguished.

The NOSServer.mycompany.com server has the Computers container replicated to it. The network operating system can then make use of the authoritative ownership and location information that the Assets department must own. Server1.mycompany.com is the authoritative server for computer

entries.