RODC mise en cache des identifiants privilégiés : le contrôleur de domaine en lecture seule qui détient les hachages Domain Admin

RODC mise en cache des identifiants privilégiés : les bases du contrôleur de domaine en lecture seule

RODC mise en cache des identifiants privilégiés — un contrôleur de domaine en lecture seule qui se retrouve avec des hachages de mots de passe de comptes qu'il n'était jamais censé voir — brise le seul modèle de menace pour lequel Microsoft a conçu les RODC. Un Read-Only Domain Controller (RODC) existe pour un type de site précis : une agence, un point de vente, une baie en colocation avec des contrôles physiques faibles — un endroit qui a besoin d'une authentification locale mais ne peut pas se voir confier une copie inscriptible de la base du domaine. La documentation de Microsoft sur le filtered attribute set et le processus de mise en cache des identifiants des RODC est explicite sur ce point : un RODC est livré sans aucun mot de passe utilisateur ou ordinateur mis en cache par défaut, et il ne met en cache un identifiant qu'après que le compte s'est réellement authentifié via lui et que la Password Replication Policy (PRP) du domaine l'autorise.

Quand cette hypothèse de conception est rompue — quand des comptes Domain Admins, Enterprise Admins, ou le compte krbtgt du domaine se retrouvent mis en cache sur la machine — toute la raison d'être du déploiement d'un RODC sur un site à faible confiance s'effondre. La compromission physique ou administrative de ce seul serveur, exactement le scénario que les RODC sont censés tolérer, produit alors du matériel Tier 0.

Il s'agit d'une faille étroite et précise, pas d'un « RODC déployé de façon générale insécurisée ». La question est de savoir quels secrets sont réellement mis en cache, vérifiés à la fois par rapport à la politique de réplication du RODC et à son historique de révélation réel — deux éléments qui dérivent indépendamment et doivent être contrôlés séparément.

Comment la Password Replication Policy est censée fonctionner

Le comportement de mise en cache de chaque RODC est régi par deux groupes locaux de domaine, selon la spécification MS-ADTS du groupe Allowed RODC Password Replication :

• Allowed RODC Password Replication Group — vide par défaut. L'appartenance (directe ou imbriquée) est le seul élément qui permet au secret d'un compte de se répliquer vers un RODC.
• Denied RODC Password Replication Group — pré-rempli par Microsoft avec les comptes qui ne doivent jamais être mis en cache.

Composition par défaut du groupe Denied

Selon les recommandations de remédiation de Microsoft sur le groupe Denied RODC Password Replication, le groupe est livré avec huit membres : krbtgt, Domain Admins, Enterprise Admins, Schema Admins, Cert Publishers, Group Policy Creator Owners, Enterprise Domain Controllers, et Enterprise Read-Only Domain Controllers. Le refus l'emporte sur l'autorisation — un compte présent à la fois dans le chemin d'autorisation et dans le chemin de refus reste refusé.

Les dérogations propres à chaque RODC vivent sur l'objet ordinateur du RODC lui-même, dans les attributs msDS-RevealOnDemandGroup et msDS-NeverRevealGroup, avec la même règle de préséance.

L'intention de la politique n'est cependant pas la même chose que la réalité. Ce qui a réellement été mis en cache — chaque secret jamais révélé à ce RODC, pas ce que la politique dit actuellement être autorisé — est suivi séparément dans l'attribut msDS-RevealedUsers sur l'objet ordinateur du RODC. Auditer la politique sans vérifier cet attribut ne renseigne que sur ce qui aurait dû se passer, pas sur ce qui s'est réellement passé. Cette distinction compte directement pour l'hygiène des comptes privilégiés Protected Users et de la délégation sur les comptes Tier 0, et pour savoir si le modèle d'administration à paliers d'un site tient réellement à la périphérie.

Quand la mise en cache tourne mal

Deux modes de défaillance distincts placent des secrets Tier 0 sur un RODC.

Mode de défaillance 1 : mauvaise configuration du chemin d'autorisation

Quelqu'un ajoute Domain Admins — ou un groupe dans lequel Domain Admins est imbriqué — au groupe Allowed RODC Password Replication, ou au msDS-RevealOnDemandGroup d'un RODC spécifique. C'est souvent « temporaire », pour dépanner un problème d'authentification sur un site, et jamais annulé. C'est précisément ce que l'ANSSI (l'agence nationale française de cybersécurité) signale dans son guide d'administration d'Active Directory, recommandation R57 (appliquer les recommandations de durcissement des RODC) : aucun compte ou groupe Tier 0 — natif ou imbriqué — ne doit apparaître dans les attributs de révélation d'un RODC, et seuls des comptes locaux au site, non Tier 0, ont leur place dans la liste d'autorisation msDS-RevealOnDemandGroup.

Mode de défaillance 2 : contournement des permissions de réplication

Indépendamment de l'appartenance aux groupes PRP, Microsoft documente une mauvaise configuration connue où le groupe Enterprise Read-Only Domain Controllers — ou un objet RODC directement — se voit accorder Replicating Directory Changes All au lieu du droit correct Replicating Directory Changes sur le naming context du domaine. C'est exactement le même droit de réplication de type DCSync que les attaquants doivent normalement voler par abus d'ACL — ici, il est remis directement au RODC. Avec ce droit, le RODC réplique tous les attributs, mots de passe compris, exactement comme un DC inscriptible. La Password Replication Policy n'est même jamais consultée, si bien que les groupes Allowed/Denied peuvent sembler parfaitement propres alors que le RODC met tout en cache quand même.

Chaque RODC obtient normalement son propre compte krbtgt par RODC, précisément pour qu'un RODC compromis ne puisse pas être utilisé pour forger des tickets valables à l'échelle du domaine. Une mauvaise configuration de mise en cache Tier 0 annule cette isolation : ce qui est exposé, c'est le krbtgt du domaine ou de véritables identifiants Domain Admin, ce qui équivaut à une compromission complète de la forêt — depuis une machine déployée au départ parce qu'elle était supposée être à faible confiance.

Détection

La configuration de la politique et l'historique réel de révélation doivent être vérifiés séparément — ils dérivent indépendamment, et une PRP qui semble propre ne garantit pas un RODC propre.

Triage rapide en PowerShell et repadmin

# Liste de révélation de vérité terrain pour un RODC spécifique
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity RODC01 -RevealedAccounts |
    Where-Object { $_.DistinguishedName -match 'CN=Domain Admins|CN=Enterprise Admins|CN=krbtgt' }

# Appartenance appliquée à la liste Allow (doit exclure les principaux Tier 0 selon la recommandation R57 de l'ANSSI)
Get-ADDomainControllerPasswordReplicationPolicy -Identity RODC01 -AppliedList

# Comparer politique et réalité face à un DC inscriptible — repadmin interroge toujours un DC inscriptible,
# ce qui permet de détecter directement le symptôme « la MMC affiche une chose, la réalité en est une autre »
repadmin /prp view RODC01.corp.local reveal

Exécutez les deux contrôles par RODC, pas une seule fois pour tout le domaine — l'appartenance aux groupes Allowed/Denied est valable pour tout le domaine, mais msDS-RevealOnDemandGroup, msDS-NeverRevealGroup et msDS-RevealedUsers sont tous des attributs propres à chaque RODC et peuvent différer d'un site à l'autre.

Remédiation

1. Videz le groupe Allowed RODC Password Replication et le msDS-RevealOnDemandGroup de chaque RODC de tout principal Tier 0, direct ou imbriqué — recommandation R57 de l'ANSSI.
2. Restaurez l'appartenance par défaut complète du groupe Denied RODC Password Replication si l'un des 8 membres par défaut a été retiré ; Microsoft recommande explicitement de ne jamais toucher à cette liste.
3. Corrigez la permission de réplication, pas seulement le groupe PRP, si dsacls montre qu'Enterprise Read-Only Domain Controllers détient Replicating Directory Changes All — accordez-lui uniquement Replicating Directory Changes, selon les recommandations de Microsoft pour cette mauvaise configuration précise.
4. Restreignez managedBy sur les objets ordinateur des RODC aux seuls comptes limités à l'administration locale de ce RODC — jamais des comptes à privilèges de domaine — pour fermer la seconde voie d'accès documentée par Sean Metcalf.
5. Surveillez en continu l'Event ID 1699 sur les DC hub inscriptibles, et intégrez une revue périodique de msDS-RevealedUsers dans un workflow d'audit AD récurrent plutôt qu'un contrôle ponctuel — la dérive de la PRP et des permissions se produit silencieusement entre deux audits.

Si un compte Tier 0 a déjà été révélé

Retirer un compte du groupe Allowed n'arrête que la réplication future — cela ne fait rien pour les secrets déjà mis en cache. Si msDS-RevealedUsers montre qu'un principal Tier 0 a un jour été révélé au RODC, l'identifiant doit être traité comme compromis : réinitialisez le mot de passe de ce compte pour que la copie mise en cache soit sans valeur. Si le krbtgt du domaine figure parmi les comptes révélés, traitez cela comme une compromission complète du domaine — réinitialisez krbtgt deux fois avec une convergence de réplication normale entre les deux réinitialisations (une seule réinitialisation ne suffit pas, car l'ancienne et la nouvelle clé coexistent brièvement), et reconstruisez le RODC depuis zéro plutôt que de continuer à lui faire confiance.

Comment EtcSec détecte cela

Le contrôle RODC_PRIVILEGED_CACHING d'EtcSec est classé Critique : il signale tout RODC où le secret d'un principal Tier 0 a réellement été mis en cache ou répliqué — pas seulement là où la politique l'autorise en théorie. Il est associé à deux contrôles de conformité directement liés au guide de l'ANSSI : ANSSI_R15_1_RODC_NO_ALLOWED_REPL (le groupe Allowed RODC Password Replication doit être vide) et ANSSI_R15_2_T0_ADMIN_REPLICATED_TO_RODC (les comptes admin Tier 0 ne doivent jamais y figurer).