How Active Directory Replication Model works.

Hello Friends, In this post i will talk about how active directory replication works.
So before answering how active directory replication works i would like to brief about what is active directory replication and what are it’s dependencies.

Active Directory replication  is the copying of data from one DC to the other DC. When any administrator makes changes on any DC that change has to be replicated to all the DC’s within the same environment so that data throughout the domain remains consistent. The benefits of AD replication are as below.

~ Prevents a single of point of failure.
~ Provides load sharing and support growth​.
~ Clients can use one of many available servers for network service.

Dependencies of AD replication.

1) DNS:- The Domain Name System (DNS) that resolves DNS names to IP
addresses. Active Directory requires that DNS is properly designed
and deployed so that domain controllers can correctly resolve DNS
names of replication partners.

2)Remote Procedure call(RPC):- Active Directory replication requires IP
connectivity and the Remote Procedure Call (RPC) to transfer updates
between replication partners.

3)Kerberos v5 authentication:- The authentication protocol for both
authentication and encryption that is required for all Active Directory
RPC replication.

Multi master replication:- Active directory support multi master replication which means that the change can be made to any DC and once the change is made it will be replicated to all the Dc’s.

When any change is made to any object , The change value must be replicated. The most interesting part to note here is that only the changed attribute is replicated not the whole object. Every has object has multiple attributes, The best example will be an user in AD can have multiple attributes like username, password, Email etc. You can see the object attributes by the running the below command.

Repadmin /showobjmeta servername “Distinguished name of the object”.

I am attaching the snapshot of the same.

In the above snapshot we have many information however if you see the column Attributes , You will be able to see all the attributes for the user msft. If msft user changes the password  then the password attribute will be replicated but  not the whole msft object. At the time of replication, only the current value of an attribute that has changed is replicated. If an attribute value has changed multiple times between replication cycles (for example, between scheduled occurrences of intersite replication), only the current value is replicated.

Active Directory data is separated in different partitions so when AD replication happens the data from one of these partition is replicated. There are 4 types of AD partitions.

1)Domain data that is stored in domain directory partitions

2)Configuration data:- Every domain controller stores one writable configuration
directory partition that stores forest-wide data controlling site and replication
operations.

3)Schema data:- Every domain controller stores one writable schema partition that
stores schema definitions for the forest. Although the schema directory partition
is writable, schema updates are allowed on only the domain controller that holds
the role of schema operations master.

4)Application data:- Domain controllers that are running Windows Server 2003 can
store directory partitions that store application data. Application directory
partition replicas can be replicated to any set of domain controllers in a forest,
irrespective of domain.

We can make only four types of changes in Active Directory hence only these four types of changes can be replicated.

1)Add an object to the directory:- An Add request makes a new object with a unique objectGUID attribute. The values of all replicated attributes that are set by the
Add request are stamped Version = 1. This GUID can be seen from adsiedit.msc

2)Modify (add, delete, or replace) attribute values of an object in the directory:-
Add:- The attribute value is added.
Delete:- The attribute value is replaced by NULL.
Replace;- Replace the attribute  value with the current value.
3)Move an object by changing the name or parent of the object.
4)Delete an object from the directory.:- Sets the isDeleted attribute to TRUE, which marks the object as a tombstone (an object that has been deleted but not fully removed from the directory).

Active Directory uses Update sequence Number (USN) for tracking and managing  updates which has to be replicated. Update sequence number is an increasing local counter of a DC. Update sequence Number can never run backwards. A source domain controller uses USNs to determine what changes have already been received by a destination domain controller that is requesting changes. The destination domain controller uses USNs to determine what changes it needs to request.

USN is a 64-bit counter that is maintained by each Active Directory domain controller as the highestCommittedUsn attribute on the rootDSE object. At the start of each update transaction (originating or replicated), the domain controller increments its current USN and associates this new value with the update request. You can see this value in adsiedit.msc as well as using repadmin command line.

Before we dig more in to USN to understand AD replication , It is very important to understand few terminology.

1)Local USN:- Every attribute of an object has it’s own USN so local USN is the USN of each attribute of an object. If you see the first picture of this post , you will be able to see the local USN of all the attributes of msft user. You can see the local usn of all the attributes of an object by running the below command.

Repadmin /showobjmeta servername “Distinguished name of the object”

2)USNChanged:-The maximum local USN among all of an object’s
attributes is stored as the object’s USNChanged attribute. You can see this USNchanged
attribute from adsiedit.msc on the object properties.

3)Originating USN: For an originating write only, the update’s USN value
is stored with each updated attribute as the originating USN of that
attribute. In very simple words Originating USN is the updated USN value for every attribute of an object, Again this is seen on the first image of the post. You can see the originating USN by the running the same command.
Repadmin /showobjmeta servername “Distinguished name of the object”

Let us assume a situation where we have two Domain controller DC and DC1.
We will  see how the replication will happen when we create a user mstest on Domain controller DC.When the user mstest was not created the USN of the Domain controller DC was 57513.

Now once we add the mstest user on domain controller DC , The USN of DC changes to 57521.

The USN of DC1 before the replication of the user was 37021 which after replication is increased to 37031. Now we will see the attributes of mstest user both on DC and DC1.
Below image shows the  attributes of mstest user on DC, Just after creating the user on DC.

so on the above image you can see the local USN and the originating USN of every attribute of mstest user. Since the user was created on DC the local USN and originating USN is same for all the attributes. Now let us  see the user attributes of mstest user on DC1 after the replication.

Now on the above image if you see the local USN  and originating USN is different since the originating USN is carried forwarded from DC(Source domain controller).

Now AD Replication uses two values for Replication Request Filtering.

1)Up-to-dateness vector:- The up-to-dateness vector is a value that the destination domain controller maintains for tracking the originating updates that are received from all source domain controllers. The source domain controller uses this value to reduce the set of attributes that it sends to the destination domain controller. When a destination domain controller requests changes for a directory partition, it provides its up-to-dateness vector to the source domain controller. On the basis of this value, the source domain controller can determine that the destination does or does not have an up-to-date value (or multivalue) for an attribute, and it sends updates accordingly.  The up-to-dateness vector helps the source domain controller to filter irrelevant attributes since the destination Domain controller presents  it’s  originating updates to the source DC and then after comparing the originating updates of both the DC’s updates are replicated to the destination DC.You can see the up-to-dateness vector in the output of the
repadmin /showvector command

2)High-watermark (direct up-to-dateness vector):- The high-watermark is a value that the destination domain controller maintains to keep track of the most recent change that it has received from a specific source domain controller for an object in a specific directory partition. The source domain controller uses this value to filter the objects that it considers for replication to the destination.When a destination domain controller requests changes to a directory partition from a source domain controller, the source domain controller provides the changes in increasing order of the usnChanged attribute value.the destination domain controller keeps track of the usnChanged value of the most recent object it successfully received from the source domain controller for a specific directory partition. The replication happens after comparing the usnChanged attribute of the source and destination domain controller. you can see the High-watermark value of every partition by running the below command.
repadmin /showreps /verbose , Look at the USN value for all the partitions in the below image.

Multi master Conflict Resolution Policy:- AD uses the method of volatility(Number of changes) as the first method of conflict resolution and the second method it uses is timestamp. Every attribute of an object  has a version number attached to it. when the object is created for the first time the version of all the attribute is given the value 1. When any attribute of any object is changed then the version number of that attribute is increased by 1 so if the password is changed for a user for the first time then the version number for password attribute will change from 1 to 2. The version number with greater value comes in to effect  during conflict. let us assume some scenarios to understand the Multimaster Conflict Resolution Policy.

Senario 1 :- We have two Domain controller DC and DC1, The password attribute of the user mstest is changed on DC and the email attribute of the user mstest is changed on DC1. The version number  of password attribute is changed from 1 to 2 in DC and the version number of email attribute is changed from 1 to 2 in DC1 , Remember the password attribute’s version number(which is 1) didn’t change in DC1 and so is the  Email attribute’s version number(Which is 1) in DC. When the replication will happen the version number(value=2) of password  attribute of DC > version number(value=1) of password attribute of DC1 hence password of DC will come in to effect . The version number(value=2) of Email attribute of DC1> Version number(value=1) of email attribute of DC so email address of DC1 will come in to effect.

Scenario 2:- We have two Domain controller DC and DC1, The password attribute of the user mstest is changed on DC and the same attribute of mstest object is changed on DC1. In this scenario the version number for password attribute is increased to 2 on both the Domain controller’s DC and DC1, now it is a tie so AD uses the time stamp as the second method for conflict resolution. The password of the Domain controller with the latest time time stamp will come in to effect. You can see the version of all the attributes of an object by running the below command.

Repadmin /showobjmeta servername “Distinguished name of the object”

I have tried to cover all the important points that should be covered under Active Directory replication however if you feel that i haven’t touched any point then feel free to leave a comment so that i can discuss the same topic on my next post.