This blog series on Active Directory Domain Services (AD DS) is designed to help you gain a good working knowledge of what Active Directory (AD) is. Each successive blog sheds light on some aspects of AD. All blogs are curated to include the right mix of AD theoretical basics along with some valuable hands-on exercises.
Through the earlier parts of the blog series, it has become clear that AD DS installed in a Windows environment opens up a host of benefits to organizations. The introduction of AD DS makes the management of permissions and access privileges very efficient. Administrators can also centrally monitor the data that is stored in AD.
In parts 3 and 4, we covered how to create AD objects such as users, groups, and OUs. AD object creation happens through administrative actions on a particular domain controller (DC). However, information like this on newly created objects should be quickly made available to all other DCs so that management actions can be performed smoothly from any DC.
AD replication enables the availability of updated AD information throughout all DCs. This blog will help you understand AD replication in depth.
So, what is AD replication?
In the most simplest sense, replication is the concept of modifying AD objects on one DC, and then have this replicated and visible on all other DCs of the AD forest.
Why is AD replication necessary?
You may be wondering what qualifies as a modification to an AD object and why such a replication model is necessary.
There are many constant changes to the AD environment that happen in real time. These changes have to be updated in the AD database for future use and management.
Examples of such changes include:
-
The addition of new users or computers in AD.
-
A change to stored AD attributes, like a rename of an AD object.
-
The movement of AD objects between OUs or AD groups.
-
The deletion of AD objects.
In order to make sure that the dynamic nature of any AD environment is maintained and its benefits are utilized effectively, replication in AD is a critical necessity that forms the backbone of AD services.
Core AD concepts needed to understand AD replication
The main objective of having an AD-controlled environment is to have centralized control and manage all users and computers efficiently.
The design of the AD logical topology mimics the structure of the business organization. It is designed to take into account the physical TCP/IP networks over which AD is set up.
In an active AD environment:
-
The installation of AD DS involves having one or more authenticating and authorizing servers called the domain controller (DC) servicing the various clients in the AD domain.
-
Each DC can be identified by a server object in AD, along with an associated Windows NT Directory Services (NTDS) child object. These NTDS objects in turn store child connections and ensure that the changes made to AD objects (users, computers, groups, or OUs) on any single DC get replicated as per a schedule to all the other receiving DCs.
-
AD sites include subnets that cover a range of IP addresses that the organization uses. One or more DCs operating in these defined sites will have the authority over AD objects present in these individual sites. Configuring these AD sites correctly plays a huge role in ensuring that there are no errors in establishing effective replication topology.
-
Active Directory Sites and Services is a management tool accessible from Server Manager. It enables administrators to configure appropriate sites and subnets, and establish site links for replication.
How does replication work?
|
Replication procedure |
Explanation |
|
Replication always occurs between two or more DCs. |
All DCs have a built-in background program called the knowledge consistency checker (KCC) that automatically creates connections between sites, establishes the associated site links, and selects bridgehead servers, which we will soon be discussing in more detail. |
|
Replication in AD happens at the attribute level. |
Every security principal such as an AD user or group is identified by a security ID (SID), and a relative ID (RID). AD objects such as computers or printers are also assigned a globally unique identifier (GUID). Only the attribute that undergoes modification along with the GUID of the modified AD object is shared between DCs or the chosen replication partners. This is done to conserve network bandwidth and ensure optimum network traffic and timely completion of the replication process. The version number on the GUID/SID is updated incrementally for each modification that occurs. |
|
Replication is made possible because of site links. |
Site links establish connections between AD sites in a manner that represents the physical networks of the organization. Faultless configuration of site link objects in AD help to determine the replication interval, replication frequency within said time interval, and the preferred replication paths between the required AD sites. The schedule and cost of site links involves the assignment of priorities in the form of numerical values. This ultimately determines the best replication path to be taken between DCs. An administrator usually makes this decision during the process of site links configuration and KCC configuration setup. |
Any error in AD replication usually happens because of incorrect configuration of AD sites and subnets, or if the KCC is not working properly, or due to any errors in AD-DNS related integrations (covered in Part 2 of this series).
Types of AD replication
There are two types of AD replication: intra-site and inter-site.
Intra-site replication
- The DCs within an AD site are arranged in ring topology, i.e. each DC is connected to two other DCs by default. There is no need for any manual intervention to create these site linkages. Refer to figure 1.
Figure 1 shows the ring topology of DCs within a site.
-
The KCC, responsible for configuring these site links and creating the replication topology through a topology generation algorithm, calls on a remote procedure call, i.e. RPC over IP, to communicate with the AD database and therefore enables the replication process. This protocol enables high-speed communication of the required changes to all the other DCs within the site through the interaction of the KCC with the directory system agent of the AD database on the DC.
-
As and when changes are authorized on a particular DC, a change notification is sent out to the other DCs in this site. These other DCs are the replication partners that respond to this notification or change update. They send out a change request directed towards the source DC. The first direct replication partner is now chosen by the source DC and is sent the required changes or replication data.
- Each DC is configured by administrators to wait for a short duration before sending the change update and subsequent replication data to every direct replication partner. As shown in Figure 2, the default time lag of 15 seconds is followed on all Windows Server 2003 computers and higher versions to ensure that network traffic is controlled and replication conflicts or errors are avoided.
Figure 2 shows DCs in sample Site A showing change notification starting in wait times of 15 seconds.
- In such well-connected sites with high network speeds, replication across all DCs within a site is usually completed within a minute after the first change notification is initiated by the source DC. The source DC sends out the replication data to all other replication partners in a timely fashion with a default time lag of three seconds between each DC.
- When there are more DCs in the site, more site links are automatically configured by the KCC to ensure that the replication is still completed effectively within the site. Figure 3 below that depicts this.
Figure 3 shows the revised replication topology in the sample Site A showing the inclusion of more DCs.
Inter-site replication
- Replication between sites happens with the identification and involvement of designated bridgehead servers as shown in Figure 4. These servers are either selected automatically by the KCC or can be configured manually by the administrator. They represent the chosen servers to enable AD data passageway between sites.
Figure 4 shows bridgehead servers establishing the path for inter-site replication to occur between sample sites A and B.
- Inter-site replication also, predominantly, happens through RPC over IP. However, when RPC over IP communication is facing issues, then SMTP may also be used. SMTP site transfers are generally less reliable and are not useful to handle all of the replication requirements in AD. Changes to Group Policy, for example, are not handled by this protocol. SMTP can only used in inter-domain replication when schema or configuration AD data has to be replicated. The replication of AD data when SMTP is used happens through email messages.
- Replication between sites is set to happen at a standard time interval of 180 minutes as shown in Figure 5. This time lag can be configured manually to different intervals. It is set at this default to take into account the lower network speeds that might affect network traffic between two AD sites.
Figure 5 shows inter-site replication between sample sites A and B. Here the time interval between replication initiation is 180 minutes between the designated bridgehead servers.
- Once the bridgehead server has received the replicated data, change notifications and subsequent replication information is communicated to and completed at all the other DCs within each of the sites involved.
Replication in practical circumstances
Let us now go over a practical example of both intra-site and inter-site replication.
Say that a new user is created in site A. The information about this new user created in site A will first be replicated to all DCs within the site. This information will then be replicated to DCs in site B.
Intra-site replication happens as follows: The source DC in site A, DC server 1, responsible for authorizing this new user creation completes the modification. After this, it initiates intra-site replication to the other DCs within this site.
Inter-site replication begins next: The designated bridgehead server in site A will then communicate this new update of user creation to the bridgehead server in another site B as per the set replication schedule for inter-site replication. The updated user information is then replicated to the other DCs in site B.
This process of replication continues between the various sites of an AD environment and is repeated each time a change modification is initiated at any of the source DCs in any site of the AD set up.
Replication, as you can see, is one of the most important aspects of Active Directory. We have now learned to dig deeper and understand AD better, and so the inter-relationships between different aspects of AD will start to become clear. Stay tuned for more!
