RODC Privileged Credential Caching: Read-Only Domain Controller Holds Domain Admin Hashes

RODC Privileged Credential Caching: Read-Only Domain Controller Basics

RODC privileged credential caching — read-only domain controller deployments ending up with password hashes for accounts they were never supposed to see — breaks the one threat model Microsoft designed RODCs around. A Read-Only Domain Controller exists for a specific kind of site: a branch office, a retail location, a colo rack with weak physical controls — somewhere that needs local authentication but can't be trusted with a writable copy of the domain database. Microsoft's own guidance on the RODC filtered attribute set and credential caching process is explicit about this: an RODC ships with no user or computer passwords cached by default, and it caches a credential only after the account has actually authenticated through it and the domain's Password Replication Policy (PRP) allows it.

When that design assumption breaks — when Domain Admins, Enterprise Admins, or the domain's krbtgt account end up cached on the box — the entire premise of deploying an RODC at a low-trust site is gone. Physical or administrative compromise of that one server, exactly the scenario RODCs exist to tolerate, now yields Tier 0 material.

This is a narrow, specific gap, not "RODC deployed insecurely" in general. It's about which secrets are actually cached, verified against both the RODC's replication policy and its live reveal history — two things that drift independently and have to be checked separately.

How the Password Replication Policy Is Supposed to Work

Every RODC's caching behavior is governed by two domain local groups, per the MS-ADTS Allowed RODC Password Replication Group specification:

• Allowed RODC Password Replication Group — empty by default. Membership (direct or nested) is the only thing that lets an account's secret replicate to an RODC.
• Denied RODC Password Replication Group — pre-populated by Microsoft with the accounts that must never be cached.

Default Denied Group Membership

Per Microsoft's remediation guidance on the Denied RODC Password Replication Group, the group ships with eight members: krbtgt, Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Enterprise Domain Controllers, and Enterprise Read-Only Domain Controllers. Deny beats allow — an account listed in both the allow and deny paths is still denied.

Per-RODC overrides live on the RODC's own computer object, in the msDS-RevealOnDemandGroup and msDS-NeverRevealGroup attributes, same precedence rule applies there.

Policy intent isn't the same thing as reality, though. What has actually been cached — every secret ever revealed to that RODC, not what the policy currently says should be allowed — is tracked separately in the msDS-RevealedUsers attribute on the RODC's computer object. Auditing policy without checking this attribute only tells you what should have happened, not what did. This distinction matters directly for Protected Users and delegation hygiene on Tier 0 accounts, and for whether a site's tiered admin model actually holds at the edge.

When Caching Goes Wrong

Two distinct failure modes put Tier 0 secrets on an RODC.

Failure Mode 1: Allow-Path Misconfiguration

Someone adds Domain Admins — or a group Domain Admins is nested in — to the Allowed RODC Password Replication Group, or to a specific RODC's msDS-RevealOnDemandGroup. Often it's "temporary," for troubleshooting a site-authentication issue, and never reverted. This is precisely what ANSSI (the French national cybersecurity agency) flags in its Active Directory administration guide, recommendation R57 (apply RODC hardening guidance): no Tier 0 account or group — built-in or nested — may appear in an RODC's reveal attributes, and only site-local, non-Tier-0 accounts belong in its msDS-RevealOnDemandGroup allow-list.

Failure Mode 2: Replication Permission Bypass

Independent of PRP group membership, Microsoft documents a known misconfiguration where the Enterprise Read-Only Domain Controllers group — or an RODC object directly — is granted Replicating Directory Changes All instead of the correct Replicating Directory Changes on the domain naming context. That is the same DCSync-class replication right attackers normally have to steal through ACL abuse — here it's handed to the RODC outright. With it, the RODC replicates every attribute, including passwords, exactly like a writable DC. The Password Replication Policy is never even consulted, so the Allowed/Denied groups can look perfectly clean while the RODC caches everything anyway.

Each RODC normally gets its own per-RODC krbtgt account specifically so a compromised RODC can't be used to forge tickets valid domain-wide. A Tier 0 caching misconfiguration defeats that isolation: what gets exposed is the domain's krbtgt or actual Domain Admin credentials, which is equivalent to full forest compromise — from a box that was deployed in the first place because it was assumed to be low-trust.

Detection

Policy configuration and actual reveal history have to be checked separately — they drift independently, and a clean-looking PRP doesn't guarantee a clean RODC.

Quick PowerShell and repadmin Triage

# Ground-truth reveal list for a specific RODC
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts |
    Where-Object { $_.DistinguishedName -match 'CN=Domain Admins|CN=Enterprise Admins|CN=krbtgt' }

# Applied Allow-list membership (should exclude Tier 0 principals per ANSSI R57)
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AppliedList

# Compare policy vs. reality against a writable DC — repadmin always hits a writable DC,
# so this catches the "MMC shows one thing, reality is another" symptom directly
repadmin /prp view RODC01.corp.local reveal

Run both checks per RODC, not once for the domain — Allowed/Denied group membership is domain-wide, but msDS-RevealOnDemandGroup, msDS-NeverRevealGroup, and msDS-RevealedUsers are all per-RODC attributes and can differ site to site.

Remediation

1. Empty the Allowed RODC Password Replication Group and every RODC's msDS-RevealOnDemandGroup of Tier 0 principals, direct or nested — ANSSI R57.
2. Restore the Denied RODC Password Replication Group's full default membership if any of the 8 defaults were removed; Microsoft explicitly recommends never touching this list.
3. Fix the replication permission, not just the PRP group, if dsacls shows Enterprise Read-Only Domain Controllers holding Replicating Directory Changes All — grant it Replicating Directory Changes only, per Microsoft's guidance for this exact misconfiguration.
4. Restrict managedBy on RODC computer objects to accounts scoped for local administration of that RODC only — never domain-privileged accounts — closing the second access path Sean Metcalf documented.
5. Monitor Event ID 1699 on writable hub DCs on an ongoing basis, and fold periodic msDS-RevealedUsers review into a recurring AD audit workflow rather than a one-time check — PRP and permission drift both happen silently between audits.

If a Tier 0 Account Was Already Revealed

Removing an account from the Allowed group only stops future replication — it does nothing to secrets already cached. If msDS-RevealedUsers shows a Tier 0 principal was ever revealed to the RODC, the credential has to be treated as compromised: reset that account's password so the cached copy is worthless. If the domain's krbtgt was among the revealed accounts, treat it as a full domain compromise — reset krbtgt twice with normal replication convergence between resets (a single reset is not sufficient, since old and new keys briefly coexist), and rebuild the RODC from scratch rather than continuing to trust it.

How EtcSec Detects This

EtcSec's RODC_PRIVILEGED_CACHING check is rated Critical: it flags any RODC where a Tier 0 principal's secret has actually been cached or replicated — not just where policy theoretically allows it. It's paired with two compliance checks mapped directly to ANSSI's guide: ANSSI_R15_1_RODC_NO_ALLOWED_REPL (Allowed RODC Password Replication Group must be empty) and ANSSI_R15_2_T0_ADMIN_REPLICATED_TO_RODC (Tier 0 admins must never appear in it).