Disrupting and Repairing Active Directory Replication

Disrupting and Repairing Active Directory Replication

July 21, 2024
4 min read
lab sysadmin +4
Table of Contents
index

Introduction

Active Directory (AD) is like the brain of many IT environments. It handles authentication, authorization, and all that good stuff. But stuff can and will go wrong eventually.

We’re going to intentionally disrupt AD replication between two domain controllers and then bring it back to life. Think of it as a controlled experiment to learn how AD replication works, and more importantly, how to troubleshoot it when things go sideways.

The Scenario

Imagine a scenario where your organization relies on two Windows Server 2019-based domain controllers. Replication between these controllers is crucial for maintaining consistency across the AD forest. However, for testing purposes or troubleshooting, lets disrupt this synchronization.

Environment: Two Windows Server 2019 VM’s with Active Domain Services installed and configured.

Objective: Break their replication bond (nicely!) by tweaking some AD object attributes, then fix it.

Constraints: No manipulation of services or network settings on domain controllers (DCs). Replication disruption must occur “internally,” operating solely on AD objects and/or schema. All services must remain live, and the network should function properly. (this is all about working inside AD itself.)

The Approach

Prerequisites

  • Spin up two Windows Server 2019 VMs and install Active Directory on both.
  • Make sure they’re replicating happily (for now).
  • Create test users to simulate real-world scenarios.

Attribute Manipulation:

Now comes the fun part; disrupting replication by tweaking an attribute that AD holds dear: the “whenCreated” timestamp. By default, this attribute is not modifiable; it only shows the “View” option. To work around this limitation, we can use the LDP (LDAP Data Interchange Format) tool.

  1. Connect to the domain controller using LDP, authenticate, and modify the “schemaUpgradeInProgress” attribute to the value “1.” This bypasses essential restrictions on attribute manipulation.
  2. Find the Distinguished Name (DN) of the “student1” User and identify the format of the attribute you want to manipulate.
  3. In this case we modify the “whenCreated” attribute to a new timestamp (e.g., set it to a date in the past).
  4. Observe how this affects replication.
powershell terminal
repadmin /replsum

You should see errors pop up like “A local object with this GUID already exists.” Just like that you’ve successfully broken replication because our modification creates a conflict which the server can’t replicate due to newer changes.

Since the whenCreated is an immutable value the error happens even before the USN comparison. It creates a mismatch between the main and the replica DC, the GUID remains the same but the metadata (date) that isn’t supposed to change is different hence the GUID error during replication.

Recovery from Replication Conflict:

Use tools like repadmin or PowerShell to pinpoint which object is causing the conflict (spoiler: it’s student1).

To restore replication identify the conflicting object (e.g., the “student1” User) and delete it.

powershell terminal
Remove-ADUser -Identity student1

Replication should resume.

Conclusion

Active Directory might seem complex at first, but once you start looking around under the hood, you realize it’s just a finely tuned machine with lots of moving parts. This project was all about understanding those parts and learning how to troubleshoot when things go wrong.