What is the Knowledge Consistency Checker (KCC) in Active Directory?

The Knowledge Consistency Checker (KCC) is the process responsible for building and maintaining the replication topology in Active Directory. If it fails or gets misconfigured, domain controllers fall out of sync, authentication breaks, and Group Policy stops applying consistently across your environment.

This article covers what the KCC is, how it builds replication topology for intrasite and intersite scenarios, the components it interacts with, how to monitor and troubleshoot it, the security risks attackers exploit through AD replication, and how ADAudit Plus gives you centralized visibility into replication health.

What is the Knowledge Consistency Checker (KCC)?

The KCC is a process that runs within the Local Security Authority Subsystem Service (LSASS) on every domain controller in an Active Directory forest. Its job is to automatically generate the replication topology by creating, modifying, and deleting connection objects in AD Sites and Services. These connection objects define one-way, inbound replication agreements between domain controllers.

By default, the KCC runs every 15 minutes, though you can adjust this interval. Each DC runs its own instance of the KCC independently, but the algorithm produces a consistent topology across the forest. The KCC makes sure every domain controller can replicate every naming context it holds: the domain partition, configuration partition, schema partition, and any application partitions.

The KCC operates in two modes: intrasite topology generation (within a single AD site) and intersite topology generation (between sites). Each uses a different algorithm and produces a different topology shape.

KCC at a glance:

How the KCC works

Intrasite replication topology

Within a single AD site, the KCC creates a bidirectional ring of connection objects linking every domain controller that holds the same naming context. The algorithm makes sure no DC is more than three replication hops from any other DC in the site, keeping replication latency low across the local network.

Intrasite replication is change-notification based. When a change occurs on a DC, that DC notifies its replication partners within about 15 seconds, and the partners pull the update. If a DC fails, the KCC detects the failure during its next run and recalculates the topology to route around the unavailable DC.

This self-healing behavior is one of the KCC's most useful properties. You don't have to intervene when a DC goes down temporarily; the KCC quietly reroutes replication on its own.

Intersite replication topology

Intersite topology works differently. One domain controller in each AD site is designated as the Inter-Site Topology Generator (ISTG). The ISTG runs the KCC's intersite algorithm, which uses site link objects to build a minimum-cost spanning tree between sites.

Site link cost, replication schedule, and replication interval all feed into the ISTG's calculations.

Bridgehead servers are the replication endpoints between sites. The KCC can select bridgehead servers automatically, or you can designate them manually in AD Sites and Services. Intersite replication follows the schedule and interval defined on site links, with a default interval of 180 minutes.

Unlike intrasite replication, intersite replication compresses data by default to conserve WAN bandwidth.

Connection objects

Connection objects are one-way, inbound replication agreements stored in the AD configuration partition. When the KCC creates a connection object, it tags it as "automatic." Administrators can also create "manual" connection objects through AD Sites and Services.

The distinction matters. The KCC recalculates automatic connection objects on every run and may modify or remove them if the topology changes. Manual connection objects are never touched by the KCC.

They persist even if they become suboptimal, which is why too many manual connections can actually interfere with the KCC's ability to optimize the topology.

Intrasite vs. intersite replication:

KCC and related AD replication components

Several AD components interact closely with the KCC. Here's how they fit together.

NTDS.dit is the Active Directory database file stored on each domain controller. The KCC's entire purpose is to keep NTDS.dit synchronized across all DCs by maintaining a complete replication topology.

SYSVOL is the replicated folder containing Group Policy templates and logon scripts. SYSVOL replication (through DFS-R on modern domains or the older FRS) is separate from AD replication, but it relies on the same site topology the KCC builds.

FSMO roles are not managed by the KCC, but FSMO role holders depend on healthy replication to function correctly. The PDC Emulator, RID Master, and Infrastructure Master all require timely replication to operate as expected.

Site links and site link bridges are the inputs the KCC's intersite algorithm uses to calculate the spanning tree topology. The cost value assigned to each site link directly influences which replication paths the ISTG selects.

How to monitor and troubleshoot the KCC

Commands for KCC health

Event IDs to watch

Common KCC issues and causes

Security risks related to AD replication

The replication infrastructure the KCC manages is the same infrastructure attackers exploit to extract credentials and inject malicious changes into Active Directory. Even if your day-to-day work is mostly operational, replication abuse is worth understanding because it's one of the quieter ways an environment gets compromised.

DCSync attack

A DCSync attack happens when an attacker with Replicating Directory Changes and Replicating Directory Changes All permissions (or a compromised account that holds these rights, such as a Domain Admin) uses the Directory Replication Service (DRS) Remote Protocol to request password hashes from a domain controller. The attack mimics legitimate DC-to-DC replication, so it rides on the same replication infrastructure the KCC builds.

Because DCSync doesn't require malware on the DC itself, it's hard to detect without monitoring replication requests at the source level. DCSync is documented as MITRE ATT&CK® technique T1003.006.

DCShadow attack

In a DCShadow attack, an attacker registers a rogue domain controller in the AD configuration partition, injects malicious changes (like adding a controlled account to Domain Admins), and then forces replication of those changes to legitimate DCs. The KCC would recognize the rogue DC and potentially create connection objects to it, propagating the attacker's modifications across the forest. DCShadow is documented as MITRE ATT&CK® technique T1207.

Replication abuse for credential theft

Attackers who gain Replicating Directory Changes All permission changes can extract the full contents of the NTDS.dit database remotely without ever touching the domain controller's file system. This permission is specifically checked during the replication operations that the KCC facilitates.

Stale or orphaned DCs as attack vectors

A decommissioned domain controller that wasn't properly cleaned up from AD (metadata not removed) leaves residual objects in the configuration partition. An attacker who joins a machine with the same computer name could potentially inherit residual replication trust, creating an entry point into the replication topology.

ADAudit Plus detects DCSync and DCShadow attacks through its Attack Surface Analyzer, which monitors for replication requests originating from non-DC sources and alerts on rogue DC registration attempts in the configuration partition.

Limitations of native tools for monitoring the KCC

Native tools like repadmin, dcdiag, and Event Viewer work for point-in-time diagnostics, but they fall short for ongoing KCC and replication monitoring in production environments. Here's where the gaps show up.

No centralized view. You have to run repadmin /showrepl on each domain controller individually, or write scripts to aggregate output across all DCs. In a multi-site environment with dozens of domain controllers, this gets old fast.

No real-time alerting. Event Viewer records KCC events like 1311, 1865, and 1925, but getting an alert when these events fire requires configuring Task Scheduler on each DC for each event. There's no built-in way to send an email or create a ticket the moment replication fails.

No historical trend analysis. repadmin /replsummary shows a point-in-time snapshot of replication health. It doesn't track whether replication failures are increasing over time or correlate failures to specific time windows, like a nightly backup job that causes replication latency.

No attribute-level replication audit. Native tools show that replication succeeded or failed at the naming context level. They don't show which specific attributes were replicated or changed during a replication cycle, so you can't trace what data actually propagated across DCs.

No cross-correlation with AD changes. When a replication failure occurs, native tools don't automatically link it to the AD change that triggered the replication. A bulk user modification that caused replication latency, for example, requires manual investigation across multiple logs.

Limited log retention. The Directory Service event log has a default maximum size of 64 MB. In busy environments, KCC events can be overwritten within days, destroying the forensic data you need to troubleshoot recurring replication issues.

Monitoring AD replication with ADAudit Plus

What ADAudit Plus monitors for AD replication

ADAudit Plus provides dedicated replication audit reports under Server Audit > Replication that give you centralized visibility into replication health without running repadmin on individual DCs.

The Replication Failures report surfaces all failed replication events with error details, identifying the specific DC pair and naming context that failed. The Replication Failure Details report provides granular error information for each failure, including the error code and the specific replication operation involved.

The Replica Sync History report tracks the complete history of replication synchronization between DCs, including timestamps, source and destination DCs, naming contexts, and sync status. The AD Object Attributes Replication report tracks attribute-level replication events, showing which specific attributes were replicated. Native tools simply can't do this.

The Lingering Objects Removed From Replica report detects and records lingering object cleanup events. These matter because they indicate replication has been broken for longer than the tombstone lifetime.

The Replica Source NC Changes and Replica Destination NC Changes reports track changes to the source and destination naming contexts in the replication topology.

Beyond replication-specific reports, ADAudit Plus detects DCSync and DCShadow attacks through the Attack Surface Analyzer, which monitors for replication requests from non-DC sources and rogue DC registration in real time. Real-time alerts can be configured to notify you by email or SMS the moment a replication failure or suspicious replication request occurs.

Native tools vs. ADAudit Plus for replication monitoring

Frequently asked questions