Read-only domain controllers (RODC) : promesses, limites et réalité forensique

Concept

Introduit avec Windows Server 2008, le Read-Only Domain Controller (RODC) est un contrôleur de domaine hébergeant des partitions d’annuaire Active Directory en lecture seule :

Base NTDS en lecture seule : les applications et administrateurs ne peuvent écrire aucun objet dans l’annuaire du RODC ; toute écriture est redirigée vers un contrôleur de domaine en écriture (RWDC).
KDC séparé et compte krbtgt dédié : chaque RODC possède son propre compte krbtgt distinct (nommé krbtgt_XXXXX), évitant que la compromission du RODC ne permette de forger des Golden Tickets sur l’ensemble du domaine.
Politique de réplication des mots de passe (PRP) : définit quels comptes ont le droit de voir leurs hashs de mots de passe mis en cache sur le RODC (Allowed List vs Denied List).

Pourquoi c’est important en DFIR

Lorsqu’un incident survient sur une succursale hébergeant un RODC :

Confinement du périmètre de compromission : si un attaquant vole physiquement le serveur RODC ou dumpe sa base ntds.dit, il n’obtient que les hashs des comptes mis en cache localement. Les comptes d’administration du domaine (Domain Admins, Enterprise Admins) figurent par défaut dans la liste de refus (Denied List) et ne sont jamais présents sur le RODC.
Réinitialisation ciblée des comptes : l’annuaire Active Directory conserve sur le RWDC la liste exacte des comptes dont le mot de passe a été mis en cache sur ce RODC (attribut msDS-RevealedUsers). L’équipe de remédiation sait exactement quels comptes réinitialiser sans devoir impacter toute l’entreprise.
Révocation du compte krbtgt_XXXXX : réinitialiser le compte krbtgt principal du domaine n’est pas nécessaire en cas de compromission isolée d’un RODC : il suffit de réinitialiser le compte krbtgt_XXXXX spécifique à ce RODC.

Comment ça fonctionne

La password replication Policy (PRP) et l’authentification

Utilisateur sur site distant                     RODC                           RWDC (Siège)
         │                                         │                                  │
         │ 1. TGT-REQ                              │                                  │
         ├────────────────────────────────────────►│                                  │
         │                                         │ 2. Le hash est-il en cache ?     │
         │                                         │    -> NON                        │
         │                                         │ 3. Transmet la requête           │
         │                                         ├─────────────────────────────────►│
         │                                         │                                  │ 4. Valide credentials
         │                                         │                                  │    Vérifie la PRP
         │                                         │ 5. Renvoie TGT + Hash si permis  │
         │                                         │◄─────────────────────────────────┤
         │                                         │ 6. Met en cache le hash (PRP OK) │
         │◄────────────────────────────────────────┤                                  │
         │ 7. Renvoie TGT signé par krbtgt_XXXXX   │                                  │

Par défaut, la denied list bloque tous les privilèges :
- Enterprise Admins, Domain Admins, Administrators, Backup Operators, Account Operators, Server Operators.
- Tous les comptes de contrôleurs de domaine (Domain Controllers).
L’allowed list définit les utilisateurs locaux :
- Typiquement un groupe Site-Branch-Users contenant les employés physiques de l’agence.

Ce qui est possible

Extraire la liste exacte des mots de passe exposés lors du vol d’un RODC : l’attribut msDS-RevealedUsers sur l’objet RODC du RWDC liste l’intégralité des SIDs dont le secret a été répliqué sur ce serveur.
Émettre des TGTs locaux valides : le KDC du RODC chiffre les TGTs avec sa propre clé krbtgt_XXXXX. Ces tickets sont acceptés par les autres DC de la forêt grâce à la réplication de la clé du RODC sur les RWDC.
Déléguer l’administration locale du RODC : un utilisateur local peut être administrateur local de l’OS du RODC sans détenir aucun droit d’administration sur l’annuaire Active Directory.

Ce qui n’est pas possible

Forger un golden ticket pour tout le domaine depuis un RODC : la clé krbtgt_XXXXX n’est reconnue que pour les comptes autorisés par la PRP. Un ticket forgé pour Domain Admins avec cette clé est rejeté par les RWDCs.
Modifier des objets d’annuaire directement sur le RODC : toute tentative d’écriture LDAP renvoie une référence LDAP (LDAP_REFERRAL) pointant vers un RWDC.
Mettre en cache le mot de passe d’un membre de Domain Admins : même si un administrateur tente d’ajouter un Domain Admin dans l’Allowed List, la Denied List prévaut systématiquement dans l’évaluation de la PRP.

Confusions fréquentes en DFIR

Confusion fréquente	Réalité forensique vérifiable
« L’attaquant a volé le fichier ntds.dit du RODC, donc tous les comptes du domaine sont compromis. »	Faux. La base `ntds.dit` d’un RODC ne contient que les hashs des comptes autorisés par la PRP et effectivement mis en cache.
« Il faut réinitialiser le compte krbtgt du domaine suite au vol d’un RODC. »	Inutile. Seul le compte `krbtgt_XXXXX` associé au RODC concerné doit être réinitialisé ou supprimé.
« Un RODC ne peut pas faire de DCSync. »	Un RODC n’a pas les droits pour faire un DCSync de comptes arbitraires ; il ne peut répliquer que les comptes validés par sa PRP auprès d’un RWDC.

Exemple concret d’investigation

Un cambriolage a lieu dans l’agence régionale de Lyon. Le serveur physique hébergeant le contrôleur de domaine RODC-LYON a été dérobé.

L’équipe DFIR se connecte sur le RWDC central du siège :
Exécution de la commande PowerShell : Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC-LYON" -Revealed
Le résultat affiche 42 comptes utilisateurs locaux de l’agence de Lyon et 2 comptes de services d’impression locaux.
Aucun compte d’administration centrale ne figure dans la liste.
Mesures de remédiation prises :
- Réinitialisation des mots de passe des 44 comptes révélés.
- Suppression de l’objet ordinateur RODC-LYON dans l’Active Directory (ce qui supprime automatiquement krbtgt_12894).
- Le domaine principal reste totalement sain sans perturbation opérationnelle globale.

Artefacts et traces forensiques

Attributs Active Directory sur l’objet compte d’ordinateur du RODC :
- msDS-RevealedUsers : liste des SIDs des comptes dont les secrets sont présents sur le RODC.
- msDS-KrbTgtLinkBl : lien vers le compte krbtgt_XXXXX associé.
Journaux de sécurité sur les RWDC :
- Event ID 4929 : modification de la politique de réplication des mots de passe d’un RODC.
- Event ID 4930 : réplication d’un secret de compte vers un RODC.
Journaux de sécurité sur le RODC :
- Event ID 4768 : émission de TGT local par le compte krbtgt_XXXXX.

Méthodes d’investigation

Extraire la liste des comptes révélés : Interroger Get-ADDomainControllerPasswordReplicationPolicyUsage -Revealed sur le RWDC central.
Vérifier l’intégrité de la PRP denied list : Confirmer que les groupes privilégiés (Administrators, Domain Admins) n’ont pas été retirés de la liste d’exclusion.
Révoquer le compte KRBTGT spécifique au RODC : Supprimer l’objet RODC ou réinitialiser son compte krbtgt_XXXXX dédié.

Outils d’investigation

PowerShell Active Directory module :

# Lister les comptes dont les mots de passe sont mis en cache sur le RODC
Get-ADDomainControllerPasswordReplicationPolicyUsage -Identity "RODC01" -Revealed |
  Select-Object SamAccountName, DistinguishedName

# Vérifier la politique PRP configurée
Get-ADDomainControllerPasswordReplicationPolicy -Identity "RODC01"

Repadmin (Windows natif) :

repadmin /prp view RODC01
repadmin /prp query RODC01 revealed

Points clés à retenir

Le RODC isole les sites distants en limitant les mots de passe stockés en mémoire et sur disque.
Les groupes administratifs sont strictement interdits de réplication par défaut via la PRP Denied List.
Chaque RODC dispose d’un compte krbtgt_XXXXX dédié, empêchant la forge de Golden Tickets globaux.
L’attribut msDS-RevealedUsers permet un confinement forensique parfait en cas de vol matériel.