RODC almacenamiento en caché de credenciales privilegiadas: el controlador de dominio de solo lectura que guarda los hashes de Domain Admin

RODC almacenamiento en caché de credenciales privilegiadas: fundamentos del controlador de dominio de solo lectura

RODC almacenamiento en caché de credenciales privilegiadas — despliegues de Read-Only Domain Controller que terminan con hashes de contraseña de cuentas que nunca debieron ver — rompe el único modelo de amenaza para el que Microsoft diseñó los RODC. Un Read-Only Domain Controller (RODC) existe para un tipo de sitio muy concreto: una oficina remota, un punto de venta, un rack en colocation con controles físicos débiles — un lugar que necesita autenticación local pero al que no se le puede confiar una copia editable de la base de datos del dominio. La guía de Microsoft sobre el filtered attribute set y el proceso de almacenamiento en caché de credenciales de los RODC es explícita al respecto: un RODC se entrega sin ninguna contraseña de usuario o de equipo en caché por defecto, y solo almacena en caché una credencial después de que la cuenta se haya autenticado realmente a través de él y la Password Replication Policy (PRP) del dominio lo permita.

Cuando esa premisa de diseño se rompe — cuando cuentas de Domain Admins, Enterprise Admins o la cuenta krbtgt del dominio terminan en caché en la máquina — desaparece toda la razón de ser de desplegar un RODC en un sitio de baja confianza. El compromiso físico o administrativo de ese único servidor, exactamente el escenario que los RODC existen para tolerar, produce entonces material Tier 0.

Se trata de una brecha estrecha y específica, no de un «RODC desplegado de forma insegura» en general. Lo que importa es qué secretos están realmente en caché, verificado tanto contra la política de replicación del RODC como contra su historial real de revelación — dos cosas que derivan de forma independiente y deben comprobarse por separado.

Cómo se supone que funciona la Password Replication Policy

El comportamiento de caché de cada RODC está gobernado por dos grupos locales de dominio, según la especificación MS-ADTS del grupo Allowed RODC Password Replication:

• Allowed RODC Password Replication Group — vacío por defecto. La pertenencia (directa o anidada) es lo único que permite que el secreto de una cuenta se replique a un RODC.
• Denied RODC Password Replication Group — pre-poblado por Microsoft con las cuentas que nunca deben almacenarse en caché.

Membresía por defecto del grupo Denied

Según la guía de remediación de Microsoft sobre el grupo Denied RODC Password Replication, el grupo se entrega con ocho miembros: krbtgt, Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Enterprise Domain Controllers y Enterprise Read-Only Domain Controllers. La denegación gana a la autorización — una cuenta listada tanto en la ruta de autorización como en la de denegación sigue denegada.

Las excepciones por RODC viven en el propio objeto de equipo del RODC, en los atributos msDS-RevealOnDemandGroup y msDS-NeverRevealGroup, con la misma regla de precedencia.

Sin embargo, la intención de la política no es lo mismo que la realidad. Lo que realmente se ha almacenado en caché — cada secreto jamás revelado a ese RODC, no lo que la política dice actualmente que debería estar permitido — se rastrea por separado en el atributo msDS-RevealedUsers del objeto de equipo del RODC. Auditar la política sin comprobar este atributo solo indica lo que debería haber pasado, no lo que realmente pasó. Esta distinción importa directamente para la higiene de Protected Users y la delegación en cuentas privilegiadas en cuentas Tier 0, y para saber si el modelo de administración por niveles de un sitio realmente se sostiene en el borde.

Cuándo el almacenamiento en caché sale mal

Dos modos de fallo distintos colocan secretos Tier 0 en un RODC.

Modo de fallo 1: mala configuración de la ruta de autorización

Alguien añade Domain Admins — o un grupo en el que Domain Admins está anidado — al grupo Allowed RODC Password Replication, o al msDS-RevealOnDemandGroup de un RODC concreto. A menudo es «temporal», para solucionar un problema de autenticación en un sitio, y nunca se revierte. Esto es exactamente lo que ANSSI (la agencia nacional francesa de ciberseguridad) señala en su guía de administración de Active Directory, recomendación R57 (aplicar la guía de hardening de RODC): ninguna cuenta o grupo Tier 0 — nativo o anidado — debe aparecer en los atributos de revelación de un RODC, y solo cuentas locales del sitio, no Tier 0, pertenecen a la lista de permitidos msDS-RevealOnDemandGroup.

Modo de fallo 2: bypass de permisos de replicación

Independientemente de la pertenencia a los grupos de la PRP, Microsoft documenta una mala configuración conocida en la que al grupo Enterprise Read-Only Domain Controllers — o directamente a un objeto RODC — se le concede Replicating Directory Changes All en lugar del permiso correcto Replicating Directory Changes sobre el naming context del dominio. Es exactamente el mismo derecho de replicación de tipo DCSync que los atacantes normalmente tienen que robar mediante abuso de ACL — aquí se le entrega directamente al RODC. Con ese derecho, el RODC replica todos los atributos, contraseñas incluidas, exactamente igual que un DC editable. La Password Replication Policy ni siquiera se consulta, por lo que los grupos Allowed/Denied pueden parecer perfectamente limpios mientras el RODC lo almacena todo en caché igualmente.

Cada RODC obtiene normalmente su propia cuenta krbtgt por RODC, precisamente para que un RODC comprometido no pueda usarse para falsificar tickets válidos en todo el dominio. Una mala configuración de caché Tier 0 anula ese aislamiento: lo que queda expuesto es el krbtgt del dominio o credenciales reales de Domain Admin, lo que equivale a un compromiso completo del bosque — desde una máquina que se desplegó precisamente porque se asumía que era de baja confianza.

Detección

La configuración de la política y el historial real de revelación deben comprobarse por separado — derivan de forma independiente, y una PRP que se ve limpia no garantiza un RODC limpio.

Triaje rápido con PowerShell y repadmin

# Lista de revelación de verdad de campo para un RODC concreto
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts |
    Where-Object { $_.DistinguishedName -match 'CN=Domain Admins|CN=Enterprise Admins|CN=krbtgt' }

# Pertenencia aplicada a la lista Allow (debe excluir principales Tier 0 según la recomendación R57 de ANSSI)
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AppliedList

# Comparar política vs. realidad contra un DC editable — repadmin siempre consulta un DC editable,
# lo que detecta directamente el síntoma «la MMC muestra una cosa, la realidad es otra»
repadmin /prp view RODC01.corp.local reveal

Ejecute ambas comprobaciones por RODC, no una sola vez para todo el dominio — la pertenencia a los grupos Allowed/Denied es de ámbito de dominio, pero msDS-RevealOnDemandGroup, msDS-NeverRevealGroup y msDS-RevealedUsers son todos atributos por RODC y pueden diferir de un sitio a otro.

Remediación

1. Vacíe el grupo Allowed RODC Password Replication y el msDS-RevealOnDemandGroup de cada RODC de principales Tier 0, directos o anidados — recomendación R57 de ANSSI.
2. Restaure la membresía completa por defecto del grupo Denied RODC Password Replication si se eliminó alguno de los 8 miembros por defecto; Microsoft recomienda explícitamente no tocar nunca esta lista.
3. Corrija el permiso de replicación, no solo el grupo de la PRP, si dsacls muestra que Enterprise Read-Only Domain Controllers tiene Replicating Directory Changes All — concédale solo Replicating Directory Changes, según la guía de Microsoft para esta mala configuración exacta.
4. Restrinja managedBy en los objetos de equipo de los RODC a cuentas limitadas a la administración local de ese RODC — nunca cuentas con privilegios de dominio — cerrando la segunda vía de acceso documentada por Sean Metcalf.
5. Monitorice de forma continua el Event ID 1699 en los DC hub editables, e incorpore la revisión periódica de msDS-RevealedUsers a un flujo de auditoría de AD recurrente en lugar de una comprobación puntual — tanto la PRP como los permisos derivan en silencio entre auditorías.

Si ya se reveló una cuenta Tier 0

Quitar una cuenta del grupo Allowed solo detiene la replicación futura — no hace nada con los secretos ya en caché. Si msDS-RevealedUsers muestra que un principal Tier 0 fue revelado alguna vez al RODC, la credencial debe tratarse como comprometida: restablezca la contraseña de esa cuenta para que la copia en caché quede inútil. Si el krbtgt del dominio estaba entre las cuentas reveladas, trátelo como un compromiso completo del dominio — restablezca krbtgt dos veces con convergencia de replicación normal entre ambos restablecimientos (un único restablecimiento no basta, ya que la clave antigua y la nueva coexisten brevemente), y reconstruya el RODC desde cero en lugar de seguir confiando en él.

Cómo lo detecta EtcSec

El chequeo RODC_PRIVILEGED_CACHING de EtcSec está clasificado como Crítico: señala cualquier RODC donde el secreto de un principal Tier 0 se haya almacenado en caché o replicado realmente — no solo donde la política lo permita en teoría. Va acompañado de dos chequeos de cumplimiento mapeados directamente a la guía de ANSSI: ANSSI_R15_1_RODC_NO_ALLOWED_REPL (el grupo Allowed RODC Password Replication debe estar vacío) y ANSSI_R15_2_T0_ADMIN_REPLICATED_TO_RODC (los administradores Tier 0 nunca deben aparecer en él).