How AD Domain Controllers Sync Schemas

Introduction

Active Directory (AD) is Microsoft’s identity and access management service built on LDAP and Kerberos. Large organizations run multiple Domain Controllers (DCs) for redundancy — any DC can authenticate users and authorize access. For this to work, all DCs must maintain an identical copy of the directory database. This synchronization is handled by AD Replication, a multi-master system where any DC can accept writes and changes are propagated to all others.

AD stores data in several directory partitions: the Domain partition (user/computer objects), Configuration partition (site topology), and Schema partition (attribute/class definitions). Each partition replicates independently.

Step-by-Step: How Replication Works

flowchart TD
    A["1. Update Sequence Numbers (USN)"]
    B["2. Replication Topology (KCC)"]
    C["3. Change Notification (Intra-Site)"]
    D["4. Conflict Resolution (Originating Write Wins)"]
    E["5. Schema Partition Replication"]
    A --> B
    B --> C
    C --> D
    D --> E

Step 1: Update Sequence Numbers (USN)

Every DC maintains a monotonically increasing Update Sequence Number (USN). Each time an object is modified, the DC stamps it with its current USN and increments the counter. DCs also maintain a High-Watermark Vector (HWM) — a table recording the highest USN they’ve received from every other DC.

DC1 USN table:
  DC1: 4523 (local writes)
  DC2: 3891 (last received from DC2)
  DC3: 2204 (last received from DC3)

Step 2: Replication Topology (KCC)

The Knowledge Consistency Checker (KCC) automatically generates a replication topology ensuring every DC is reachable within 3 hops. It creates connection objects between DCs within a site (intra-site, 15-second latency) and between sites (inter-site, configurable via site links).

# View replication topology
repadmin /showrepl
repadmin /replsummary

# Force immediate replication
repadmin /syncall /AdeP

Step 3: Change Notification (Intra-Site)

Within a site, when DC1 makes a change, it waits 15 seconds then sends a change notification to its replication partners. Partners request the changes using a GetNCChanges RPC call, sending their current HWM. DC1 responds with all objects modified since that USN.

Step 4: Conflict Resolution (Originating Write Wins)

When two DCs simultaneously modify the same attribute, AD uses attribute-level conflict resolution:

1. Higher version number wins
2. On tie: later timestamp wins
3. On tie: higher GUID wins

Step 5: Schema Partition Replication

Schema changes (adding new attributes/classes) replicate through the Schema partition, which has a single Schema Master FSMO role to prevent conflicts. Schema changes must be applied on the Schema Master then replicate outward.

# Check Schema Master
netdom query fsmo

# Force schema partition replication
repadmin /replicate DC2 DC1 "CN=Schema,CN=Configuration,DC=corp,DC=example,DC=com"

Key Takeaways

• AD uses USN-based change tracking (not timestamps) as the primary replication mechanism, with timestamps only as a tiebreaker.
• The KCC automatically builds a replication topology ensuring no DC is more than 3 hops from any other.
• FSMO roles (Schema Master, RID Master, PDC Emulator, etc.) prevent write conflicts on sensitive operations.
• Intra-site replication triggers on change notification (15-second delay); inter-site replication uses scheduled intervals via site link objects.
• Use repadmin /showrepl and repadmin /replsummary to diagnose replication failures.