Active Directory Replication Health: How to Monitor, Diagnose, and Secure AD Replication
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
AD replication health is an operational concern that has direct security implications. A DC that is behind in replication may not have the latest password change for a user whose account was compromised and reset, may not have a GPO update that closes a security misconfiguration, and may not have the disable or delete for an account that should have been offboarded. Monitoring replication health is therefore part of the security program, not just the infrastructure team's responsibility. This guide covers the key commands, monitoring approach, and the replication anomalies that specifically matter to security.
Daily Replication Health Check with repadmin
Run these commands from any DC with Domain Admin privileges: repadmin /replsummary -- provides a table showing each DC, the number of replication failures, the largest delta (time since last successful replication), and any error codes. A healthy output shows 0 failures and deltas within the replication schedule (typically under 60 minutes). Any DC showing failures or large deltas needs investigation. repadmin /showrepl -- shows the detailed replication status for each naming context (Configuration, Schema, Domain, ForestDnsZones, DomainDnsZones) per replication partner. Failures show the error code and last successful replication time. repadmin /rehost -- forces a replication from all partners (useful for testing or forcing a stale DC to catch up). dcdiag /test:replications /verbose -- runs the replication diagnostic across all DCs and reports errors with diagnostic context. For automation: script repadmin /showrepl * /csv > repl-report.csv and parse for non-zero error counts in a monitoring pipeline. Common error codes: 1256 (remote system is not available -- network issue), 1722 (RPC unavailable -- firewall or service issue), 8453 (replication access denied -- trust or permission issue), 8614 (DC cannot replicate -- too far behind, lingering objects).
Security-Relevant Replication Failures
Not all replication failures are equal from a security standpoint. Priority failures that have security implications: Error 8453 (replication access denied): indicates the DC's computer account or replication service account lacks the required directory replication permissions. This can result from accidental ACL changes on the domain root (removing the 'Replicating Directory Changes' right) or from a compromised admin removing replication rights to isolate a rogue DC. Alert immediately on this error. Error 8614 (cannot replicate because of lingering objects): indicates a DC has been offline long enough that objects deleted on other DCs still exist on this DC (the AD tombstone lifetime, default 180 days, was exceeded while the DC was offline). This can result from a DC that an attacker has isolated or controlled. Lingering objects can include user or computer accounts that were deleted on healthy DCs but persist on the isolated DC -- allowing the attacker to authenticate against the stale DC. Replication metadata anomalies: a sudden change in replication topology (new replication links, changed bridgehead servers) may indicate an attacker modifying the AD Sites and Services configuration to redirect replication through a compromised DC.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Detect and Respond to USN Rollback
USN (Update Sequence Number) rollback occurs when a DC is restored from a snapshot or backup without using the proper AD-aware restore procedures (specifically, without using 'authoritative' or 'nonauthoritative' restore modes that handle the USN correctly). The restored DC has lower USNs than replication partners expect, causing partners to ignore its updates (they think they already have them) or to be confused about what has been replicated. USN rollback produces Event ID 2095 (replication partner rejected update) and Event ID 1988 (lingering objects detected). Detecting USN rollback: Event ID 2095 on any DC -- check for this in your SIEM. The dcdiag /test:checksecurityerror test also detects USN rollback conditions. Response: a DC in USN rollback state cannot be reliably fixed -- it must be demoted (dcpromo /forceremoval if normal demotion fails), removed from DNS and AD, and rebuilt. Never attempt to 'force' past a USN rollback -- it corrupts replication data for the domain. Prevention: do not restore DCs from hypervisor snapshots unless using VM-GenerationID-aware hypervisors (Hyper-V, VMware with the VMware Tools AD plug-in) that detect snapshot restoration and trigger safe NTDS recovery automatically.
Monitor Replication via Event IDs in Your SIEM
Key replication-related events to forward from DCs: Event ID 1864 (Knowledge Consistency Checker -- domain controller is not replicating within the tombstone lifetime). Event ID 2042 (DC has not replicated within tombstone lifetime -- lingering objects). Event ID 2087 (DNS lookup failure for replication partner -- most common cause of replication failure). Event ID 2095 (USN rollback detected). Event ID 1988 (lingering object encountered during replication). Security-specifically relevant: Event ID 4662 on the domain root object with replication GUIDs (as covered in DCSync detection) -- this is a legitimate replication call from a real DC, but if it appears from a non-DC workstation IP, it is a DCSync attack. Correlate 4662 events with the list of known DC IP addresses. Monitor for new DCs being promoted without proper change management processes -- Event ID 29213 (NTDS -- directory replication agent completed setup) from an unexpected server indicates an unauthorized DC promotion.
Replication Security Hardening
Protect the replication infrastructure: verify the 'Replicating Directory Changes' and 'Replicating Directory Changes All' permissions on the domain root are assigned only to Domain Controllers and Domain Admins (check in ADSI Edit or PowerShell: Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Properties 'nTSecurityDescriptor' and review the ACL). Remove any non-DC service accounts or users from these permission sets -- they are only required for legitimate replication (DCs) and DCSync-based backup tools (which should use dedicated accounts with scoped replication rights). Enable and monitor AD DS diagnostic logging (set HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\5 Replication Events = 5 for verbose logging -- use during troubleshooting only, not long-term). Ensure all DCs are patched -- replication protocol vulnerabilities (like Zerologon CVE-2020-1472 which affected Netlogon, the protocol underlying some replication authentication) can be exploited to compromise the replication trust.
The bottom line
AD replication health monitoring belongs in both the operations runbook and the security monitoring program. Run repadmin /replsummary daily. Alert on Event IDs 2095 (USN rollback) and 8453 (replication access denied) as potential security incidents. Verify that only DCs and explicitly authorized accounts have Replicating Directory Changes rights. A DC with replication failures may be an operations issue or evidence of attacker activity -- investigate both possibilities.
Frequently asked questions
How often does AD replication normally occur?
Within a site, replication is triggered within 15 seconds of a change (for urgent changes like password resets, it is immediate via urgent replication). Non-urgent changes are batched and replicated within 15 seconds to 15 minutes depending on the configured notification delay. Between sites, replication frequency is controlled by the Site Link schedule and interval -- default is every 3 hours but organizations typically configure 15-30 minute intervals for production. The maximum replication lag before objects are considered stale is the tombstone lifetime (180 days default) -- a DC offline longer than this cannot be safely reintegrated.
What is the SYSVOL replication and how does it relate to GPO security?
SYSVOL replication distributes Group Policy templates and scripts across all DCs. Modern environments use DFSR (Distributed File System Replication) for SYSVOL; legacy environments use the older FRS (File Replication Service). SYSVOL replication failures mean GPO changes do not reach all DCs -- a security GPO hardening change may apply on some endpoints (whose logon DC has the updated GPO) but not others. Verify SYSVOL replication health with: dfsrdiag ReplicationState /Member:[DCname] and check the DFSR event log. SYSVOL replication failures produce Event IDs 4604 and 4612 in the DFSR operational log.
Can replication be used as an attack vector?
DCSync is the primary replication-based attack -- it uses the AD replication protocol to request password hashes from a DC as if the attacker were a replication partner. It does not require code on a DC; only network connectivity and an account with the Replicating Directory Changes All right. Less commonly, an attacker who has compromised a DC can manipulate the replication topology to route certain replication traffic through their controlled DC, potentially allowing interception or modification. This is a sophisticated attack that requires DC-level access and is mitigated by monitoring AD Sites and Services for unauthorized topology changes.
How do I force AD replication to verify a change has propagated?
To force immediate replication from a specific DC: repadmin /syncall /AdeP [TargetDC]. The flags: /A = all naming contexts, /d = identify servers by DN, /e = enterprise (cross-site), /P = push changes outward. To verify a specific change has propagated to all DCs: make the change, note the timestamp, then run repadmin /showattr * <DistinguishedName> to query the attribute value from all DCs. Alternatively, use the AD Replication Status Tool (a Microsoft download) for GUI-based replication health monitoring and ad-hoc replication forcing.
How does a compromised domain controller use replication to spread an attack?
A compromised DC participates in normal replication and can introduce malicious changes into the AD database that replicate to all other DCs: creating new admin accounts, modifying group memberships (adding the attacker's account to Domain Admins), changing user passwords (all replicate to the domain's authoritative copy within the normal replication schedule). More subtly, a compromised DC can manipulate its own replication metadata to delay propagation of remediation actions applied on other DCs, buying the attacker more time. During incident response involving a suspected compromised DC: demote or isolate it before attempting remediation on other DCs, and verify that remediation changes have propagated across all remaining healthy DCs using repadmin /showattr.
How do you detect Active Directory replication failures that could indicate a DCShadow attack or a split-brain scenario?
DCShadow is an attack technique where an attacker registers a rogue DC in Active Directory and uses it to push malicious replication data. Detection relies on finding unauthorized DC registrations. Repadmin /showrepl and repadmin /replsummary expose all replication partners -- any DC name not in your documented DC inventory is suspicious. Entra Connect Health for AD DS and Microsoft Defender for Identity both monitor replication topology and alert on unexpected replication partners. For split-brain detection (USN rollback scenarios where a DC's update sequence number went backward after an improper snapshot restore): Event IDs 2095 and 2103 on a DC indicate it detected a USN rollback in a replication partner. If a DC detects this, it stops replicating from that partner to prevent corruption -- the DC will have Event ID 2095 logged. Fix by either seizing FSMO roles from the problematic DC or performing an authoritative restore. Monitor replication lag using repadmin /showrepl with the /errorsonly flag in your monitoring tooling -- any site with replication errors older than 24 hours warrants immediate investigation.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.