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

RODC Privileged Credential Caching: Grundlagen zum Read-Only Domain Controller

RODC Privileged Credential Caching — wenn Read-Only-Domain-Controller-Bereitstellungen am Ende Passwort-Hashes für Konten besitzen, die sie eigentlich nie sehen sollten — bricht mit genau dem Bedrohungsmodell, für das Microsoft RODCs konzipiert hat. Ein Read-Only Domain Controller existiert für eine bestimmte Art von Standort: eine Zweigstelle, eine Filiale, ein Colocation-Rack mit schwachen physischen Schutzmaßnahmen — irgendwo, wo lokale Authentifizierung benötigt wird, dem aber keine beschreibbare Kopie der Domänendatenbank anvertraut werden kann. Microsofts eigene Anleitung zum RODC Filtered Attribute Set und Credential-Caching-Prozess ist hier eindeutig: Ein RODC wird standardmäßig ohne zwischengespeicherte Benutzer- oder Computerpasswörter ausgeliefert und cached ein Credential erst, nachdem sich das jeweilige Konto tatsächlich über ihn authentifiziert hat und die Password Replication Policy (PRP) der Domäne dies zulässt.

Wenn diese Design-Annahme bricht — wenn Domain Admins, Enterprise Admins oder das krbtgt-Konto der Domäne am Ende auf dem Server zwischengespeichert sind —, ist die gesamte Grundlage für den Einsatz eines RODC an einem Standort mit geringem Vertrauen hinfällig. Eine physische oder administrative Kompromittierung genau dieses einen Servers — exakt das Szenario, das RODCs eigentlich tolerieren sollen — liefert dann Tier-0-Material.

Das ist eine enge, spezifische Lücke, nicht „RODC allgemein unsicher bereitgestellt". Es geht darum, welche Geheimnisse tatsächlich zwischengespeichert sind — verifiziert sowohl gegen die Replikationsrichtlinie des RODC als auch gegen seine tatsächliche Reveal-Historie —, zwei Dinge, die unabhängig voneinander driften und deshalb getrennt geprüft werden müssen.

Wie die Password Replication Policy funktionieren soll

Das Caching-Verhalten jedes RODC wird von zwei domänenlokalen Gruppen gesteuert, gemäß der MS-ADTS-Spezifikation zur Allowed RODC Password Replication Group:

• Allowed RODC Password Replication Group — standardmäßig leer. Nur die (direkte oder verschachtelte) Mitgliedschaft in dieser Gruppe erlaubt, dass das Secret eines Kontos zu einem RODC repliziert wird.
• Denied RODC Password Replication Group — von Microsoft mit den Konten vorbefüllt, die niemals zwischengespeichert werden dürfen.

Standardmitgliedschaft der Denied-Gruppe

Laut Microsofts Remediation-Anleitung zur Denied RODC Password Replication Group wird die Gruppe mit acht Mitgliedern ausgeliefert: krbtgt, Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Enterprise Domain Controllers und Enterprise Read-Only Domain Controllers. Deny schlägt Allow — ein Konto, das sowohl im Allow- als auch im Deny-Pfad aufgeführt ist, bleibt trotzdem verweigert.

Pro-RODC-Overrides liegen auf dem eigenen Computerobjekt des RODC, in den Attributen msDS-RevealOnDemandGroup und msDS-NeverRevealGroup — dieselbe Vorrangregel gilt auch dort.

Richtlinienabsicht ist allerdings nicht dasselbe wie Realität. Was tatsächlich zwischengespeichert wurde — jedes Secret, das diesem RODC jemals offengelegt wurde, nicht das, was die Richtlinie aktuell erlaubt — wird separat im Attribut msDS-RevealedUsers auf dem Computerobjekt des RODC nachgehalten. Eine Richtlinienprüfung ohne Kontrolle dieses Attributs sagt nur, was hätte passieren sollen, nicht was tatsächlich passiert ist. Diese Unterscheidung wirkt sich direkt auf Protected Users und Delegation-Hygiene bei Tier-0-Konten aus sowie darauf, ob das gestufte Admin-Modell eines Standorts an der Peripherie wirklich standhält.

Wenn das Caching schiefgeht

Zwei unterschiedliche Fehlermodi bringen Tier-0-Secrets auf einen RODC.

Fehlermodus 1: Fehlkonfiguration im Allow-Pfad

Jemand fügt Domain Admins — oder eine Gruppe, in der Domain Admins verschachtelt sind — der Allowed RODC Password Replication Group hinzu, oder der msDS-RevealOnDemandGroup eines bestimmten RODC. Oft geschieht das „vorübergehend", zur Fehlersuche bei einem Standort-Authentifizierungsproblem, und wird nie rückgängig gemacht. Genau das benennt ANSSI (die französische nationale Cybersicherheitsbehörde) in ihrem Leitfaden zur Active-Directory-Administration, Empfehlung R57 (RODC-Härtungsvorgaben anwenden): Kein Tier-0-Konto oder -Gruppe — integriert oder verschachtelt — darf in den Reveal-Attributen eines RODC auftauchen, und nur standortlokale Nicht-Tier-0-Konten gehören in dessen msDS-RevealOnDemandGroup-Allow-Liste.

Fehlermodus 2: Umgehung der Replikationsberechtigung

Unabhängig von der PRP-Gruppenmitgliedschaft dokumentiert Microsoft eine bekannte Fehlkonfiguration, bei der der Gruppe Enterprise Read-Only Domain Controllers — oder direkt einem RODC-Objekt — Replicating Directory Changes All statt des korrekten Replicating Directory Changes auf dem Domain-Naming-Context gewährt wird. Das ist dasselbe DCSync-artige Replikationsrecht, das sich Angreifer normalerweise erst über ACL-Missbrauch erschleichen müssen — hier wird es dem RODC direkt übergeben. Damit repliziert der RODC jedes Attribut, einschließlich Passwörter, exakt wie ein beschreibbarer DC. Die Password Replication Policy wird dabei gar nicht erst konsultiert, sodass die Allowed-/Denied-Gruppen makellos sauber aussehen können, während der RODC trotzdem alles zwischenspeichert.

Jeder RODC erhält normalerweise sein eigenes RODC-spezifisches krbtgt-Konto, genau damit ein kompromittierter RODC nicht genutzt werden kann, um domänenweit gültige Tickets zu fälschen. Eine Tier-0-Caching-Fehlkonfiguration hebelt diese Isolation aus: Was offengelegt wird, ist das krbtgt der Domäne oder tatsächliche Domain-Admin-Credentials — was einer vollständigen Forest-Kompromittierung gleichkommt — und das ausgehend von einem Server, der überhaupt nur deshalb bereitgestellt wurde, weil man ihn als Low-Trust einstufte.

Erkennung

Richtlinienkonfiguration und tatsächliche Reveal-Historie müssen getrennt geprüft werden — sie driften unabhängig voneinander, und eine sauber aussehende PRP garantiert keinen sauberen RODC.

Schnelle Triage mit PowerShell und repadmin

# Ground-Truth-Reveal-Liste für einen bestimmten RODC
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts |
    Where-Object { $_.DistinguishedName -match 'CN=Domain Admins|CN=Enterprise Admins|CN=krbtgt' }

# Angewendete Allow-Listen-Mitgliedschaft (sollte Tier-0-Prinzipale gemäß ANSSI R57 ausschließen)
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AppliedList

# Richtlinie mit Realität gegen einen beschreibbaren DC abgleichen — repadmin fragt immer einen
# beschreibbaren DC ab, sodass dies das Symptom "MMC zeigt eins, Realität ist ein anderes" direkt erfasst
repadmin /prp view RODC01.corp.local reveal

Führen Sie beide Prüfungen pro RODC aus, nicht einmal für die gesamte Domäne — Allowed-/Denied-Gruppenmitgliedschaft gilt domänenweit, aber msDS-RevealOnDemandGroup, msDS-NeverRevealGroup und msDS-RevealedUsers sind allesamt Pro-RODC-Attribute und können sich von Standort zu Standort unterscheiden.

Remediation

1. Die Allowed RODC Password Replication Group und die msDS-RevealOnDemandGroup jedes RODC von Tier-0-Prinzipalen leeren, direkt oder verschachtelt — ANSSI R57.
2. Die vollständige Standardmitgliedschaft der Denied RODC Password Replication Group wiederherstellen, falls eines der 8 Standardmitglieder entfernt wurde; Microsoft rät ausdrücklich davon ab, diese Liste jemals anzufassen.
3. Die Replikationsberechtigung beheben, nicht nur die PRP-Gruppe, falls dsacls zeigt, dass Enterprise Read-Only Domain Controllers Replicating Directory Changes All besitzt — gewähren Sie stattdessen nur Replicating Directory Changes, gemäß Microsofts Anleitung für genau diese Fehlkonfiguration.
4. managedBy auf RODC-Computerobjekten einschränken auf Konten, die ausschließlich für die lokale Administration dieses einen RODC vorgesehen sind — niemals auf domänenprivilegierte Konten — und damit den zweiten von Sean Metcalf dokumentierten Zugangsweg schließen.
5. Event-ID 1699 auf beschreibbaren Hub-DCs fortlaufend überwachen und eine regelmäßige Prüfung von msDS-RevealedUsers in einen wiederkehrenden AD-Audit-Workflow einbetten statt in eine einmalige Kontrolle — sowohl PRP- als auch Berechtigungsdrift entstehen still zwischen den Audits.

Wenn ein Tier-0-Konto bereits offengelegt wurde

Ein Konto aus der Allowed-Gruppe zu entfernen stoppt nur künftige Replikation — an bereits zwischengespeicherten Secrets ändert das nichts. Zeigt msDS-RevealedUsers, dass ein Tier-0-Prinzipal jemals gegenüber dem RODC offengelegt wurde, muss das Credential als kompromittiert behandelt werden: Setzen Sie das Passwort dieses Kontos zurück, damit die zwischengespeicherte Kopie wertlos wird. War das krbtgt der Domäne unter den offengelegten Konten, behandeln Sie dies als vollständige Domain-Kompromittierung — setzen Sie krbtgt zweimal zurück, mit normaler Replikationskonvergenz zwischen den beiden Resets (ein einzelner Reset reicht nicht aus, da alte und neue Schlüssel kurzzeitig koexistieren), und bauen Sie den RODC von Grund auf neu, statt ihm weiterhin zu vertrauen.

Wie EtcSec das erkennt

Der Check RODC_PRIVILEGED_CACHING von EtcSec ist als Critical eingestuft: Er markiert jeden RODC, bei dem das Secret eines Tier-0-Prinzipals tatsächlich zwischengespeichert oder repliziert wurde — nicht nur dort, wo die Richtlinie es theoretisch erlauben würde. Er ist gepaart mit zwei Compliance-Checks, die direkt auf den ANSSI-Leitfaden abgebildet sind: ANSSI_R15_1_RODC_NO_ALLOWED_REPL (die Allowed RODC Password Replication Group muss leer sein) und ANSSI_R15_2_T0_ADMIN_REPLICATED_TO_RODC (Tier-0-Admins dürfen dort niemals auftauchen).