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.
