How does Active Directory replication work?

Active Directory (AD) is a multi-master directory, meaning each directory services server— referred to as a domain controller—contains a fully readable and writable copy of the directory services database. Because all domain controllers can accept changes to the database, some method is needed to replicate those changes to other domain controllers, ensuring a consistent database across all domain controllers. This scheme is referred to as AD replication.

AD replication can be broken down into four basic operational components:

• Who, which is a list of servers that participate in replication and the servers with which they replicate. Referred to as a replication topology, this list is generated by a special AD component called the Knowledge Consistency Checker (KCC).
• What, which is the information that is being replicated. AD uses attribute-based replication and versioning to determine which information has changed and requires replication.
• When, which is a schedule that determines when replication will occur. Separate schedules exist for replication within an AD site and for each link connecting different sites.
• How, which defines how the replicated data is physically transported across the network.

Deciding What to Replicate

AD maintains multiple attributes for each object. For example, a user object has attributes such as password, account lockout status, user name, and so forth. Each attribute is versioned independently, letting AD replicate only attribute changes. For example, when a user changes his or her password, only that particular attribute receives a new version number and is replicated to other domain controllers (rather than replicating the entire object).

Windows Server 2003 uses linked value replication to improve replication efficiency. Security groups are an example of a multivalued attribute with linked values, in which the group's multiple attributes are references to the group's members. In Windows 2000 (Win2K), changes made to a member of a group require the entire group to be replicated. In Windows Server 2003, only the group member that has changed is replicated. This feature is only available when the forest functional level is at Windows Server 2003.

Version Control

Obviously, some form of version control is necessary to determine which domain controller has the most recent version of each attribute. AD uses update sequence numbers (USNs) as a form of version number. Each USN is a 64-bit number; whenever a domain controllers changes an attribute, it increments the domain controller's USN. Each domain controller maintains only a single USN.

Each domain controller also maintains a list of USNs that have been received from other domain controllers during replication. When a domain controller informs its replication partners that changes are available for replication, its partners respond with the USN previously received from that domain controller. The sending domain controller can then send only the attributes that have changed since that USN, ensuring that data already replicated isn't replicated again. This technique also allows for domain controllers to remain offline for a period of time; when they replicate the next time, they'll receive every change that's been made since the last time they replicated. Figure 19.1 illustrates this process.

Figure 19.1: USNs and replication.

Dealing with conflicts is also important because it's possible for a single attribute to be changed on two domain controllers at once (for example, two administrators might attempt to change the same user's password at the same time). A replication collision occurs when a single attribute is changed on one domain controller, while a previous change to that attribute is still in the process of replicating. To help resolve collisions, AD maintains a property version number for each attribute in the directory. USNs are server-specific, whereas property version numbers are attached to each attribute in the directory and are replicated along with that attribute.

Changing an attribute increments its property version number. Replicating an attribute does not change its property version number; only "new" changes have that effect. Whenever a domain controller receives a replicated attribute with the same version number as the local copy, the domain controller knows a collision has occurred. In other words, another source has changed the attribute but that source hadn't first received a replicated change from a second source. The result is two changes running around the network with the same property version number. When this occurs, the domain controller receiving the change keeps the one with the latest timestamp. This situation is the only instance in which AD replication relies on timestamps and is the reason that Win2K and later includes a time synchronization service. Figure 19.2 shows how a replication collision is handled.

It's possible for an attribute to be replicated with a lower property version number. This situation can happen when the domain controller making the attribute change has missed two or more replications of that attribute from other sources. AD discards any replicated data with a lower property version number than the local copy.

Figure 19.2: Replication collisions.

For more information about how AD handles replication conflicts, see the Microsoft article "How Conflicts Are Resolved in Active Directory Replication."

Propagation Dampening

The AD replication topology allows loops—particularly within a site in which a ring-based topology is the norm. In theory, these loops could result in change being replicated infinitely around the loop. However, AD replication has a built-in propagation dampening scheme, which detects and stops looping replication data.

The dampening system uses up-to-date vectors. The vector is a list of servers within the site and a USN for each server. The vector at each server thus indicates the highest USN of new changes received from each server within the site. When a new replication cycle starts, the requesting domain controller sends its up-to-date vector to its sending replication partner. That partner, as already described, filters the changes sent to the receiving domain controller so that it only receives changes made after that USN was used. If the requesting domain controller sends a USN that is greater than or equal to the sending domain controller's own USN, then no changes need to be sent, and the replication cycle stops. Figure 19.3 shows the vectors in action.

Figure 19.3: Propagation dampening in AD replication.

When Replication Occurs

For intrasite replication, each domain controller informs its partners when it has changes available. Those partners then send a request for those changes, providing the domain controller with the USN numbers from their last replication update.

Domain controllers don't always inform their partners of changes as soon as those changes occur. For most changes, domain controllers wait about 5 minutes before sending a notification. This time period allows an administrator to make several changes and have them replicated in one batch, rather than the domain controller sending out independent change notifications for each minor change. However, certain types of security-sensitive changes—such as the lockout status of a user account—are considered high-priority and are always replicated immediately.

You can modify the default intrasite replication interval. For details, refer to the Microsoft article "How to Modify the Default Intra-Site Domain Controller Replication Interval."

Intersite replication can occur less frequently, according to a schedule that you specify. This flexibility allows you to configure replication to best utilize your available intersite WAN bandwidth. Intersite replication traffic is compressed somewhat, helping to reduce WAN bandwidth utilization. Figure 19.4 shows how you can alter the schedule for a site link, for example, to prevent replication during business hours.

Figure 19.4: Restricting replication on a site link.

How Replication Travels

Replication can use either IP or Simple Mail Transport Protocol (SMTP) as a transport. IP is the standard intrasite transport and the default intersite transport. Replication actually uses IP to carry remote procedure call (RPC) traffic, uses Kerberos to mutually authenticate both replication partners, and uses Microsoft's CryptoAPI to encrypt the replicated data for maximum security.

The SMTP transport packages replicated data in packets, which allows for disconnected sites that have only mail-based connectivity. In effect, domain controllers email each other replication data. SMTP replication can only be used between sites, and can only be used between domain controllers in different domains (which still replicate certain forest-wide information to one another). SMTP requires the use of an enterprise certificate authority (CA), which allows the domain controllers participating in replication to authenticate one another through a trusted root CA.