What you will learn from this article?
Information in the Active Directory (AD) network is modified or updated constantly. In such cases, if any information is updated in one domain controller (DC) of the AD network, all other DCs in the network should also be updated with the new information. This process is done in AD through replication. In this article, we will take a look at what is AD replication, how it works, the types of AD replication, and what will happen when information of one object is modified simultaneously at two different DCs.
A brief history of Active Directory Replication
Before Windows server 2000, Windows NT followed a master-slave approach to AD replication by employing a single writable Primary Domain controller (PDC) and multiple associated, read-only Backup Domain Controllers (BDC). After AD departed from the traditional master-slave method of replication, it now uses a multi-master approach for the replication of directory data. As the name suggests, in the multi-master approach, each domain controller acts as a master and can replicate data to the other domain controllers.
Replication across the three different directory partitions – schema partition, configuration partition, and domain partition is carried out differently. The schema container holds definitions about objects and object attributes and is ubiquitous in nature. Any update to the schema is replicated forest-wide. The configuration container contains a physical layout of sites. Similar to schema data, configuration data is also replicated throughout the forest. On the contrary, domain controllers residing in different domains, house different sets of data that are domain confined. Thus to facilitate dispersion of data throughout an organization, the data in each domain controller is completely replicated to every other domain controller in the domain and partially replicated to the global catalog server.
How does Active Directory replication work?
Now that we know how replication occurs at three levels of directory partition, it is essential to understand that Active Directory replication is attribute-based. To understand this let’s go back to our first example- the change in employees’ telephone numbers. Here “telephone number” is one of the attributes that define the object “employee”. When this attribute is modified, only the change in the attribute, that is the new telephone number, is replicated to all the domain controllers and not the entire object. Here comes the concept of Update Sequence Numbers (USN). When an object is created, by default a USN is assigned to them. Whenever a change is elicited these USNs are incremented making every other USN in other domain controllers go out of date for that object. To ensure that only the most recent changes are replicated, only the highest USN is stored and displayed. Thus changes are monitored and recorded with the help of USN in Active Directory.
Sites and Replication
Rather than managing a network as a whole, for administrative convenience, it is divided into “sites” to achieve cost efficiency and speed. In such cases when more than one site exists, the replication process is carried out differently for inter and intrasite replication. While intrasite replication occurs within a site, intersite replication takes place between sites.
Due to the higher availability of bandwidth, updates are replicated at high speed as and when made, within a site. This type of replication is unscheduled and is carried out using a bidirectional ring topology, wherein a minimum of two connections for each domain controller are established to increase fault tolerance.
While it is assumed that within a site bandwidths are very high, between two sites the bandwidth is typically restricted. Hence to save bandwidth, cost, and increase efficiency, updates replicated between sites are usually compressed and follow a configurable schedule. In addition to using RPC/IP which is employed in intrasite replication, intersite replication exercises asynchronous protocols like SMTP as well.
Configuring the topology for inter and intrasite replication is indeed painstaking, but thankfully for us, Active Directory configures its own replication topologies using Knowledge Consistency Checker(KCC). KCC is an Active Directory service that lifts the burden of generating a topology from the shoulders of an administrator. With the help of KCC, the domain controllers consolidate all the directory partition copies and disseminate the replicated information through a set of connections that span over LANs and WANs. These sets of connections together form the replication topology.
Site link objects serve as the building blocks for developing an inter-site replication topology. Each of these site link objects is assigned a “cost” and a least-cost replication topology is generated by the KCC by reducing redundant replication pathways.
AD Replication Partner
Every time a change is made in the directory it is not necessary that the source domain controller replicate the data directly to each one of the destination domain controllers. This creates too much overload on the domain controller and effectuates replication traffic. This is where a replication partner can help greatly. The KCC identifies certain domain controllers as its replication partners and transmits the replication information through them. These connection objects can either directly or transitively transfer data to the destination DC’s
AD Replication Models
Some mechanisms aid in the unhindered replication of directory updates from one DC to another. These mechanisms together, contribute to the Active Directory replication model. This model comprises four components, which integrate all the replication services.
| Component | Working |
| Multimaster replication | A peer-to-peer model of replication where each domain controller can send and receive updates when a change is effected. In the multi-master replication, all the domain controllers are vested equal powers and can initiate replication whenever the situation demands. |
| Store and forward replication | Store and forward replication eliminate point-to-point replication from one DC to another. Instead, the changes are first replicated to one particular DC, which in turn communicates the changes to its replication partners. They subsequently send it around to their own replication partners and so on until all the DCs are updated. |
| Pull replication | When a change is made in a domain controller it simply does not push those updates to other DC’s. Rather, it waits for an update request from them. Once the destination solicits specific information, the source sends it immediately helping the destination update itself. |
| State-based replication | In a state-based replication, the domain controllers replicate only the current state of the object instead of replicating the entire object itself. |
Components of Active Directory Replication
The various components of AD replication include the following:
- Knowledge Consistency Checker (KCC): A process that runs on each DC and is responsible for creating replication topologies.
- Directory System Agent (DSA): A directory service component that runs as Ntdsa.dll on each DC.
- Extensible Storage Engine (ESE): Responsible for managing directory database records, which may contain one or more columns.
- Remote Procedure Call (RPC): A communication protocol where developers can run code on a local or remote system without needing to develop a separate code for remote execution of processes.
- Intersite Topology Generator (ISTG): Responsible for managing the intersite inbound replication connection objects for a specific site. There is one ISTG server on each site.
The AD objects that the KCC and its components use are as follows:
- Sites
- Subnets
- Servers
- NTDS Settings
- Connections
- Site Links
- NTDS Site Settings
- Cross-reference
AD Replication Collisions
Though the mechanism of replication looks absolutely foolproof, there is a possibility of the same object attribute being modified concurrently by two different people from different DC’s. This gives rise to a replication collision. The catch here of course is which change must actually be replicated throughout the directory! In such cases when there are double USN updates for the object, the time stamp of the two objects are verified and the most recent timestamp is accepted. Another issue is the name collision. To understand this we need to take a peek into the user object creation process. When a user object is created, it is quintessential for its Relative Distinguished Name (RDN) to be a unique attribute within its parent OU and so should be the sAMAccountName attribute, inside a domain. If these two rules are breached, an error message prompting you to change the name of the user object pops up. But it is quite possible for two people from different DC’s to create an object with the same RDN within an OU and identical sAMAccountName within a domain at precisely the same time. In such cases AD lets the user object be created with no error message. But when replication commences, ambiguities arise. To make one object exclusive from another, the replication system attaches to the first created object, its GUID, making it unique. Thus name collisions are resolved.
