RODC cache delle credenziali privilegiate: il controller di dominio in sola lettura che conserva gli hash di Domain Admin

RODC cache delle credenziali privilegiate: le basi del controller di dominio in sola lettura

RODC cache delle credenziali privilegiate — implementazioni di Read-Only Domain Controller che finiscono per conservare hash di password di account che non avrebbero mai dovuto vedere — rompe l'unico modello di minaccia per cui Microsoft ha progettato gli RODC. Un Read-Only Domain Controller (RODC) esiste per un tipo di sito ben preciso: una filiale, un punto vendita, un rack in colocation con controlli fisici deboli — un luogo che ha bisogno di autenticazione locale ma a cui non si può affidare una copia scrivibile del database di dominio. La documentazione ufficiale di Microsoft sul filtered attribute set e il processo di caching delle credenziali degli RODC è esplicita su questo punto: un RODC viene fornito senza alcuna password di utente o computer in cache per impostazione predefinita, e mette in cache una credenziale solo dopo che l'account si è effettivamente autenticato tramite esso e la Password Replication Policy (PRP) del dominio lo consente.

Quando questo presupposto di progettazione viene meno — quando account Domain Admins, Enterprise Admins, o l'account krbtgt del dominio finiscono in cache sulla macchina — viene meno l'intera ragion d'essere del distribuire un RODC in un sito a bassa fiducia. La compromissione fisica o amministrativa di quel singolo server, esattamente lo scenario che gli RODC esistono per tollerare, produce a quel punto materiale Tier 0.

Si tratta di una falla ristretta e specifica, non di un «RODC distribuito in modo genericamente insicuro». La domanda è quali segreti siano realmente in cache, verificati sia rispetto alla policy di replica dell'RODC sia rispetto alla sua cronologia reale di reveal — due cose che divergono in modo indipendente e vanno controllate separatamente.

Come dovrebbe funzionare la Password Replication Policy

Il comportamento di caching di ogni RODC è governato da due gruppi locali di dominio, secondo la specifica MS-ADTS del gruppo Allowed RODC Password Replication:

• Allowed RODC Password Replication Group — vuoto per impostazione predefinita. L'appartenenza (diretta o annidata) è l'unica cosa che permette al segreto di un account di replicarsi verso un RODC.
• Denied RODC Password Replication Group — pre-popolato da Microsoft con gli account che non devono mai essere messi in cache.

Composizione predefinita del gruppo Denied

Secondo le linee guida di remediation di Microsoft sul gruppo Denied RODC Password Replication, il gruppo viene fornito con otto membri: krbtgt, Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Enterprise Domain Controllers ed Enterprise Read-Only Domain Controllers. Il diniego prevale sull'autorizzazione — un account presente sia nel percorso di autorizzazione sia in quello di diniego resta comunque negato.

Le eccezioni per singolo RODC risiedono sull'oggetto computer dell'RODC stesso, negli attributi msDS-RevealOnDemandGroup e msDS-NeverRevealGroup, con la stessa regola di precedenza.

L'intento della policy, però, non coincide con la realtà. Ciò che è realmente stato messo in cache — ogni segreto mai rivelato a quell'RODC, non ciò che la policy dice attualmente essere consentito — è tracciato separatamente nell'attributo msDS-RevealedUsers sull'oggetto computer dell'RODC. Verificare la policy senza controllare questo attributo racconta solo ciò che avrebbe dovuto accadere, non ciò che è realmente accaduto. Questa distinzione è direttamente rilevante per l'igiene di Protected Users e della delega sugli account privilegiati sugli account Tier 0, e per capire se il modello di amministrazione a livelli di un sito regge davvero ai margini.

Quando il caching va storto

Due modalità di errore distinte portano segreti Tier 0 su un RODC.

Modalità di errore 1: configurazione errata del percorso di autorizzazione

Qualcuno aggiunge Domain Admins — o un gruppo in cui Domain Admins è annidato — al gruppo Allowed RODC Password Replication, o al msDS-RevealOnDemandGroup di un RODC specifico. Spesso è «temporaneo», per risolvere un problema di autenticazione su un sito, e non viene mai ripristinato. È esattamente ciò che l'ANSSI (l'agenzia nazionale francese per la cybersicurezza) segnala nella sua guida all'amministrazione di Active Directory, raccomandazione R57 (applicare le linee guida di hardening degli RODC): nessun account o gruppo Tier 0 — nativo o annidato — deve comparire negli attributi di reveal di un RODC, e solo account locali al sito, non Tier 0, hanno diritto di stare nella allow-list msDS-RevealOnDemandGroup.

Modalità di errore 2: bypass dei permessi di replica

Indipendentemente dall'appartenenza ai gruppi PRP, Microsoft documenta una configurazione errata nota in cui al gruppo Enterprise Read-Only Domain Controllers — o direttamente a un oggetto RODC — viene concesso Replicating Directory Changes All invece del corretto Replicating Directory Changes sul naming context del dominio. È esattamente lo stesso diritto di replica di tipo DCSync che gli attaccanti normalmente devono rubare tramite abuso di ACL — qui viene consegnato direttamente all'RODC. Con quel diritto, l'RODC replica ogni attributo, password comprese, esattamente come un DC scrivibile. La Password Replication Policy non viene nemmeno consultata, quindi i gruppi Allowed/Denied possono apparire perfettamente puliti mentre l'RODC mette comunque tutto in cache.

Ogni RODC ottiene normalmente il proprio account krbtgt dedicato per RODC, proprio affinché un RODC compromesso non possa essere usato per forgiare ticket validi a livello di dominio. Una configurazione errata del caching Tier 0 vanifica questo isolamento: ciò che viene esposto è il krbtgt del dominio o vere credenziali Domain Admin, il che equivale a una compromissione completa della foresta — da una macchina che era stata distribuita proprio perché considerata a bassa fiducia.

Rilevamento

La configurazione della policy e la cronologia reale di reveal vanno controllate separatamente — divergono in modo indipendente, e una PRP apparentemente pulita non garantisce un RODC pulito.

Triage rapido con PowerShell e repadmin

# Elenco di reveal di verità di fatto per un RODC specifico
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts |
    Where-Object { $_.DistinguishedName -match 'CN=Domain Admins|CN=Enterprise Admins|CN=krbtgt' }

# Appartenenza applicata alla lista Allow (deve escludere principal Tier 0 secondo la raccomandazione R57 dell'ANSSI)
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AppliedList

# Confronta policy e realtà rispetto a un DC scrivibile — repadmin interroga sempre un DC scrivibile,
# individuando direttamente il sintomo "la MMC mostra una cosa, la realtà è un'altra"
repadmin /prp view RODC01.corp.local reveal

Eseguire entrambi i controlli per ogni singolo RODC, non una sola volta per l'intero dominio — l'appartenenza ai gruppi Allowed/Denied è a livello di dominio, ma msDS-RevealOnDemandGroup, msDS-NeverRevealGroup e msDS-RevealedUsers sono tutti attributi per singolo RODC e possono differire da sito a sito.

Remediation

1. Svuotare il gruppo Allowed RODC Password Replication e il msDS-RevealOnDemandGroup di ogni RODC da principal Tier 0, diretti o annidati — raccomandazione R57 dell'ANSSI.
2. Ripristinare l'appartenenza predefinita completa del gruppo Denied RODC Password Replication se uno degli 8 membri predefiniti è stato rimosso; Microsoft raccomanda esplicitamente di non toccare mai questo elenco.
3. Correggere il permesso di replica, non solo il gruppo PRP, se dsacls mostra che Enterprise Read-Only Domain Controllers detiene Replicating Directory Changes All — concedere solo Replicating Directory Changes, secondo le linee guida Microsoft per questa esatta configurazione errata.
4. Limitare managedBy sugli oggetti computer degli RODC ad account limitati all'amministrazione locale di quel RODC — mai account con privilegi di dominio — chiudendo la seconda via d'accesso documentata da Sean Metcalf.
5. Monitorare in modo continuativo l'Event ID 1699 sui DC hub scrivibili, e integrare la revisione periodica di msDS-RevealedUsers in un workflow di audit AD ricorrente invece di un controllo una tantum — sia la PRP sia i permessi divergono silenziosamente tra un audit e l'altro.

Se un account Tier 0 è già stato rivelato

Rimuovere un account dal gruppo Allowed blocca solo la replica futura — non fa nulla per i segreti già in cache. Se msDS-RevealedUsers mostra che un principal Tier 0 è stato rivelato all'RODC in qualche momento, la credenziale va trattata come compromessa: reimpostare la password di quell'account in modo che la copia in cache diventi inutile. Se il krbtgt del dominio era tra gli account rivelati, trattarlo come una compromissione completa del dominio — reimpostare krbtgt due volte con normale convergenza di replica tra i due reset (un singolo reset non è sufficiente, poiché la chiave vecchia e quella nuova coesistono brevemente), e ricostruire l'RODC da zero invece di continuare a fidarsene.

Come EtcSec rileva questo problema

Il controllo RODC_PRIVILEGED_CACHING di EtcSec è classificato come Critico: segnala qualsiasi RODC in cui il segreto di un principal Tier 0 sia stato realmente messo in cache o replicato — non solo dove la policy lo consentirebbe in teoria. È abbinato a due controlli di conformità mappati direttamente sulla guida dell'ANSSI: ANSSI_R15_1_RODC_NO_ALLOWED_REPL (il gruppo Allowed RODC Password Replication deve essere vuoto) e ANSSI_R15_2_T0_ADMIN_REPLICATED_TO_RODC (gli amministratori Tier 0 non devono mai comparirvi).