Contrôleurs de domaine en lecture seule : maîtriser la stratégie de réplication des mots de passe

Le principe du RODC

Un RODC héberge une copie en lecture seule de l'annuaire, mais par défaut sans les mots de passe des comptes. Lorsqu'un utilisateur s'authentifie auprès de lui, le RODC transmet la demande à un contrôleur accessible en écriture. Si la stratégie de réplication des mots de passe (Password Replication Policy, PRP) l'autorise, le secret du compte est ensuite mis en cache localement, ce qui permet l'authentification même en cas de coupure du lien avec le site central. Si un RODC est volé, seuls les secrets mis en cache sont exposés.

Groupes autorisés et refusés

La PRP s'appuie sur deux attributs de l'objet ordinateur du RODC : msDS-RevealOnDemandGroup (comptes autorisés) et msDS-NeverRevealGroup (comptes refusés). Par défaut, ils référencent deux groupes de domaine :

• Groupe de réplication dont le mot de passe RODC est autorisé (Allowed RODC Password Replication Group), vide à l'installation ;
• Groupe de réplication dont le mot de passe RODC est refusé (Denied RODC Password Replication Group), qui contient notamment les Admins du domaine, les Administrateurs de l'entreprise, les Administrateurs du schéma, les contrôleurs de domaine et le compte krbtgt.

Le refus l'emporte toujours sur l'autorisation. Les groupes intégrés les plus sensibles (Administrateurs, Opérateurs de compte, Opérateurs de serveur, Opérateurs de sauvegarde) figurent aussi dans la liste de refus de chaque RODC. La bonne pratique consiste à créer un groupe autorisé par agence, contenant uniquement les utilisateurs et ordinateurs de ce site, plutôt que d'alimenter le groupe autorisé global.

Ce que l'on trouve souvent en audit

• le groupe Utilisateurs du domaine ajouté à la liste autorisée « pour que ça marche », ce qui revient à mettre en cache tout le domaine ;
• des comptes d'administration ou de service à privilèges absents de la liste refusée parce qu'ils ne sont membres d'aucun groupe protégé par défaut ;
• des comptes membres du groupe refusé retirés manuellement pour résoudre un incident ponctuel ;
• des RODC dont personne ne consulte les attributs msDS-RevealedList (secrets effectivement mis en cache) et msDS-AuthenticatedToAccountList (comptes qui se sont authentifiés).

Ajoutez explicitement à la liste refusée vos groupes d'administration personnalisés, les comptes de service sensibles et tout compte de niveau 0.

Le compte krbtgt propre à chaque RODC

Chaque RODC dispose de son propre compte krbtgt_ suivi d'un numéro. Les tickets qu'il émet sont signés avec cette clé, que les contrôleurs en écriture reconnaissent et traitent avec prudence. Ce cloisonnement limite l'impact d'un RODC compromis. Pensez à réinitialiser périodiquement ces comptes comme le krbtgt principal, et à supprimer les comptes krbtgt orphelins d'anciens RODC.

Administrateurs délégués et risques en agence

L'attribut managedBy de l'objet RODC désigne un utilisateur ou un groupe qui obtient les droits d'administration locale sur le serveur, sans aucun droit sur le domaine. C'est la séparation des rôles d'administrateur. Il faut toutefois considérer ce groupe comme sensible : un administrateur local du RODC peut accéder aux secrets mis en cache. Évitez d'y placer des comptes privilégiés du domaine, qui exposeraient alors leurs propres identifiants sur un serveur moins protégé.

Ce qu'un audit vérifie

• le contenu des listes autorisées et refusées de chaque RODC ;
• la présence de comptes privilégiés dans les secrets effectivement mis en cache ;
• les titulaires de l'attribut managedBy et leurs autres privilèges ;
• la date de dernière réinitialisation des comptes krbtgt dédiés aux RODC.