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

RODC Privileged Credential Caching: Fundamentos do Read-Only Domain Controller

RODC Privileged Credential Caching — quando implantações de Read-Only Domain Controller acabam com hashes de senha de contas que nunca deveriam ver — quebra exatamente o modelo de ameaça para o qual a Microsoft projetou os RODCs. Um Read-Only Domain Controller existe para um tipo específico de site: uma filial, uma loja, um rack em colocation com controles físicos fracos — algum lugar que precisa de autenticação local, mas não pode receber uma cópia gravável do banco de dados do domínio. A própria orientação da Microsoft sobre o RODC filtered attribute set e o processo de cache de credenciais é explícita sobre isso: um RODC é implantado sem nenhuma senha de usuário ou computador em cache por padrão, e só armazena em cache uma credencial depois que a conta efetivamente se autenticou através dele e a Password Replication Policy (PRP) do domínio permite.

Quando essa premissa de design é quebrada — quando Domain Admins, Enterprise Admins ou a conta krbtgt do domínio acabam em cache no servidor —, toda a premissa de implantar um RODC em um site de baixa confiança desaparece. O comprometimento físico ou administrativo desse único servidor — exatamente o cenário que os RODCs existem para tolerar — passa a render material de Tier 0.

Essa é uma lacuna estreita e específica, não "RODC implantado de forma insegura" em termos gerais. É sobre quais segredos estão de fato em cache, verificados tanto contra a política de replicação do RODC quanto contra seu histórico real de revelações — duas coisas que derivam de forma independente e precisam ser verificadas separadamente.

Como a Password Replication Policy Deveria Funcionar

O comportamento de cache de cada RODC é governado por dois grupos locais de domínio, conforme a especificação MS-ADTS do Allowed RODC Password Replication Group:

• Allowed RODC Password Replication Group — vazio por padrão. A associação (direta ou aninhada) é a única coisa que permite que o segredo de uma conta seja replicado para um RODC.
• Denied RODC Password Replication Group — pré-preenchido pela Microsoft com as contas que nunca devem ser armazenadas em cache.

Associação Padrão do Grupo Denied

Segundo a orientação de remediação da Microsoft para o Denied RODC Password Replication Group, o grupo é implantado com oito membros: krbtgt, Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Enterprise Domain Controllers e Enterprise Read-Only Domain Controllers. Deny prevalece sobre allow — uma conta listada tanto no caminho allow quanto no deny continua sendo negada.

Overrides por RODC ficam no próprio objeto de computador do RODC, nos atributos msDS-RevealOnDemandGroup e msDS-NeverRevealGroup — a mesma regra de precedência se aplica ali também.

No entanto, a intenção da política não é o mesmo que a realidade. O que de fato foi armazenado em cache — todo segredo já revelado a esse RODC, não o que a política atualmente permite — é rastreado separadamente no atributo msDS-RevealedUsers do objeto de computador do RODC. Auditar apenas a política, sem verificar esse atributo, só mostra o que deveria ter acontecido, não o que de fato aconteceu. Essa distinção afeta diretamente as boas práticas de Protected Users e delegação em contas de Tier 0, e também se o modelo de admin em camadas de um site realmente se sustenta na borda.

Quando o Cache Dá Errado

Dois modos de falha distintos colocam segredos de Tier 0 em um RODC.

Modo de Falha 1: Configuração Incorreta no Caminho Allow

Alguém adiciona Domain Admins — ou um grupo no qual Domain Admins está aninhado — ao Allowed RODC Password Replication Group, ou ao msDS-RevealOnDemandGroup de um RODC específico. Muitas vezes isso é feito "temporariamente", para investigar um problema de autenticação no site, e nunca é revertido. É exatamente isso que a ANSSI (a agência nacional francesa de cibersegurança) sinaliza em seu guia de administração do Active Directory, recomendação R57 (aplicar a orientação de hardening de RODC): nenhuma conta ou grupo de Tier 0 — nativo ou aninhado — pode aparecer nos atributos de revelação de um RODC, e apenas contas locais do site, que não sejam Tier 0, pertencem à lista allow do msDS-RevealOnDemandGroup.

Modo de Falha 2: Bypass da Permissão de Replicação

Independentemente da associação ao grupo de PRP, a Microsoft documenta uma configuração incorreta conhecida na qual o grupo Enterprise Read-Only Domain Controllers — ou um objeto RODC diretamente — recebe Replicating Directory Changes All em vez do correto Replicating Directory Changes no domain naming context. Esse é o mesmo direito de replicação de classe DCSync que os invasores normalmente precisam roubar via abuso de ACL — aqui ele é entregue diretamente ao RODC. Com isso, o RODC replica todos os atributos, incluindo senhas, exatamente como um DC gravável. A Password Replication Policy nem sequer é consultada, de modo que os grupos Allowed/Denied podem parecer perfeitamente limpos enquanto o RODC ainda assim armazena tudo em cache.

Cada RODC normalmente recebe sua própria conta krbtgt específica exatamente para que um RODC comprometido não possa ser usado para forjar tickets válidos em todo o domínio. Uma configuração incorreta de cache de Tier 0 derruba esse isolamento: o que fica exposto é o krbtgt do domínio ou credenciais reais de Domain Admin, o que equivale a um comprometimento completo da floresta — vindo de um servidor que só foi implantado, para começar, porque era considerado de baixa confiança.

Detecção

A configuração da política e o histórico real de revelações precisam ser verificados separadamente — eles derivam de forma independente, e uma PRP com aparência limpa não garante um RODC limpo.

Triagem Rápida com PowerShell e repadmin

# Lista de revelação ground-truth para um RODC específico
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts |
    Where-Object { $_.DistinguishedName -match 'CN=Domain Admins|CN=Enterprise Admins|CN=krbtgt' }

# Associação aplicada da allow-list (deve excluir principais de Tier 0 conforme a ANSSI R57)
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AppliedList

# Compara política com realidade contra um DC gravável — o repadmin sempre consulta um DC
# gravável, então isso captura diretamente o sintoma "o MMC mostra uma coisa, a realidade é outra"
repadmin /prp view RODC01.corp.local reveal

Execute as duas verificações por RODC, não uma única vez para o domínio inteiro — a associação aos grupos Allowed/Denied vale para o domínio todo, mas msDS-RevealOnDemandGroup, msDS-NeverRevealGroup e msDS-RevealedUsers são todos atributos por RODC e podem variar de site para site.

Remediação

1. Esvazie o Allowed RODC Password Replication Group e o msDS-RevealOnDemandGroup de cada RODC de principais de Tier 0, diretos ou aninhados — ANSSI R57.
2. Restaure a associação padrão completa do Denied RODC Password Replication Group caso algum dos 8 membros padrão tenha sido removido; a Microsoft recomenda explicitamente nunca mexer nessa lista.
3. Corrija a permissão de replicação, não apenas o grupo de PRP, se o dsacls mostrar que o Enterprise Read-Only Domain Controllers detém Replicating Directory Changes All — conceda apenas Replicating Directory Changes, conforme a orientação da Microsoft para essa configuração incorreta específica.
4. Restrinja o managedBy nos objetos de computador do RODC a contas com escopo apenas para a administração local daquele RODC — nunca contas privilegiadas no domínio — fechando o segundo caminho de acesso documentado por Sean Metcalf.
5. Monitore o Event ID 1699 nos hub DCs graváveis continuamente, e incorpore a revisão periódica do msDS-RevealedUsers em um workflow recorrente de auditoria de AD em vez de uma verificação pontual — tanto a política de PRP quanto as permissões derivam silenciosamente entre auditorias.

Se uma Conta de Tier 0 Já Foi Revelada

Remover uma conta do grupo Allowed só interrompe a replicação futura — não faz nada em relação a segredos já em cache. Se o msDS-RevealedUsers mostrar que um principal de Tier 0 já foi revelado ao RODC em algum momento, a credencial precisa ser tratada como comprometida: redefina a senha dessa conta para que a cópia em cache se torne inútil. Se o krbtgt do domínio estiver entre as contas reveladas, trate isso como um comprometimento total do domínio — redefina o krbtgt duas vezes, com convergência normal de replicação entre as duas redefinições (uma única redefinição não é suficiente, já que as chaves antiga e nova coexistem brevemente), e reconstrua o RODC do zero em vez de continuar confiando nele.

Como a EtcSec Detecta Isso

O check RODC_PRIVILEGED_CACHING da EtcSec é classificado como Critical: ele sinaliza qualquer RODC onde o segredo de um principal de Tier 0 tenha sido de fato armazenado em cache ou replicado — não apenas onde a política teoricamente permitiria isso. Ele é combinado com dois checks de compliance mapeados diretamente ao guia da ANSSI: ANSSI_R15_1_RODC_NO_ALLOWED_REPL (o Allowed RODC Password Replication Group deve estar vazio) e ANSSI_R15_2_T0_ADMIN_REPLICATED_TO_RODC (admins de Tier 0 nunca podem aparecer nele).