Advanced Replication Features

The advanced replication features described in the following sections are found in some, but not all, directory implementations .

Replicating a Subset of Directory Information

In most cases, replication is used to provide complete copies of a partition. For example, in Figure 11.12 the complete subtree rooted at ou=Accounting,dc=example,dc=com is being replicated.

Figure 11.12. Replicating an Entire Subtree

In some cases, however, we might be interested in replicating only certain attributes of the entries. For example, when providing a publicly searchable directory of employee information outside a corporate firewall, an organization might elect to replicate only full names , e-mail addresses, and office telephone numbers and omit all other personal information. Notice in Figure 11.13 that the copy of John Doe's entry accessible outside the firewall contains fewer attributes than the master entry inside the firewall. A replica that contains a subset of the attributes found on a complete replica is called a fractional replica .

Figure 11.13. Replicating Only Selected Attributes from an Entry

We might also be interested in selecting only certain entries from a subtree. A reasonable thing to do would be to select entries on the basis of their object class. For example, we might want to replicate only those entries that represent people or organizational units. In Figure 11.14, the root of the replicated subtree is once again ou=Accounting,dc=example,dc=com , but only the organizationalUnit and person entries are being replicated. A replica that holds a subset of the entries of another replica is called a sparse replica .

Figure 11.14. Replicating Selected Entries

One potential complication with sparse replication is that the replicated directory may contain "holes." In the example depicted in Figure 11.14, if entries of objectclass organizationalUnit had not been selected, the replicated tree would look like the one shown in Figure 11.15. To be a valid directory tree, every entry except the root entry must have a parent; however, the consumer's directory tree violates that rule. To remedy this situation, the supplier could create on the consumer a placeholder in place of the entry that was not replicated. The X.500 model describes a specific type of placeholder, termed a glue entry , used for just this purpose.

Figure 11.15. A Hole in the DIT Arising from Sparse Replication

Although sparse and fractional replication are simple concepts, they are quite difficult to implement in a multimaster environment. Novell eDirectory is the only directory we are aware of that supports general-purpose fractional and sparse replicas. Microsoft Active Directory, however, supports a special type of fractional replica called the global catalog (GC).

Active Directory GC Servers

Microsoft Active Directory uses fractional replication to create a special replica called the global catalog , or GC . The GC is a directory that contains a subset of the attributes in each directory entry in all the Active Directory domains. Typically at least one GC is installed at each Active Directory site (an Active Directory site is a zone of high-speed network connectivity within a Windows 2000 network). The GC is used by Active Directory clients within the site when they need to search across the entire Active Directory installation.

Without the GC, an Active Directory client that wants to search across all domains must contact each domain (via referrals) and aggregate the results. With the GC, however, the client can direct its search operations at the GC server, as long as the attributes it needs to search have been replicated to the GC. For common Windows operations, such as logging in and evaluating group membership and access control rights, the GC contains all required attributes.

Scheduling Replication

In some cases a directory administrator might not want changes to be sent to all replicas immediately. For example, a remote office connected via a dial-up link might be better served if updates could be transmitted in one batch to save connect-time charges. Alternatively, a remote office connected via a slow network link might be configured to have updates propagated to a consumer server during off-hours to improve network response for other applications during working hours.

Unfortunately, scheduling replication in this fashion means that users connecting to the consumer will see old data for potentially long periods. For many applications, this is perfectly acceptable; but think carefully about any requirements you might have down the road. For example, if an employee is terminated , it may be necessary to reset his password immediately so that he cannot log in. However, if the directory is not scheduled to be updated for another eight hours, the password revocation will not make it to the consumer immediately, as required.

Scheduling Update Latency by Attribute Type

One solution to this latency problem is to incorporate a scheduling policy that propagates changes to certain attributes immediately and others less rapidly . With Novell eDirectory, for example, whereas certain attributes, such as login passwords, are propagated on a fast synchronization schedule, other attributes, such as last login timestamps in user entries, are scheduled for update on a slow synchronization schedule. This feature seeks to improve update time for critical values and defers other updates to conserve network bandwidth and server processing time.

Schemas and Replication

The purpose of replication is to provide copies of directory data in multiple physical locations. It makes sense, therefore, that supplier and consumer servers should have the same schema. Serious problems would arise, for example, if a supplier server attempted to add an entry of an object class not allowed by the consumer's schema (the operation would be rejected, and the consumer could never be brought into synchronization).

Different vendors take alternative approaches to solving this problem. Netscape Directory Server 6 has one global schema for all replicas held by a server. The schema is marked with a sequence number that represents the last time the schema was updated. Before commencing a replication session, a Netscape Directory Server 6 supplier checks whether the consumer's schema sequence number is older than its own. If it is, it sends the updated schema to the consumer and then commences the normal replication update. Schemas may be changed at any updatable replica. If two schemas are in conflict, the newer schema is used in its entirety (attribute-specific value conflict resolution is not performed), and an updated schema will eventually propagate to all servers.

Microsoft Active Directory solves the schema replication problem by using single-master replication for schemas. One server in the domain is designated as the schema master. All updates must take place at the schema master. No conflict resolution policies are required because they cannot occur in a single-master replication system.

Access Control and Replication

Virtually all directory products offer some way of controlling access to the data contained in the directory tree, usually via an access control list ( ACL ) mechanism. When the contents of the tree are replicated, it is desirable also to replicate any associated ACL information so that the same protections apply to both the replicated data and the original data. More information about access control can be found in Chapter 12, Privacy and Security Design.

Most, if not all, directory software stores ACLs as attributes of entries. Usually this means that the ACLs merely need to be replicated along with other directory content. As long as the supplier and consumer server use the same ACL syntax, and as long as those ACLs mean the same thing on both servers, their directory entries will have the same access control.

Again, in most cases it's sufficient to replicate ACLs along with directory content. The one time this gets a bit tricky is when ACLs have a scope that extends down the directory tree and crosses a unit of replication. In Figure 11.16, the entry dc=example,dc=com on the supplier server contains an access control directive that applies to all entries below it. However, this entry is not contained within the replicated subtree, so the consumer server lacks the access control information it needs to properly control access to its replicated subtree.

Figure 11.16. Access Control Information Stored above a Replicated Subtree

Netscape Directory Server 6 allows you to configure replication in this manner, so be sure when designing your replication strategy that you include ACLs at the top of all replicated subtrees. (The default in Netscape Directory Server 6 is to completely deny access in the absence of ACL information, so a problem like the one in Figure 11.16 would not expose any directory information to unauthorized access.)