Windows Server 2008 - Active Directory et les RODC
Comme vous le savez certainement un des choix d'architecture lors du design d'Active Directory était de se débarrasser de l'une des limitations des domaines NT à savoir à l'époque l'existence d'un point unique de mise à jour de la base de compte le fameux PDC.
Cet objectif a clairement été atteint puisque l'ensemble des opérations à l'exception de celles nécessitant l'un des 5 FSMO peut être réalisé sur n'importe lequel des contrôleurs d'un domaine Active Directory.
Parfait cela signifie aussi que nous sommes passé d'un modèle centralisé de mise à jour avec point de défaillance unique à un modèle distribué de mise à jour sans point de défaillance, mais en y regardant de plus près cela signifie aussi que nous avons globalement accru la surface d'exposition de l'annuaire dans la mesure le vol ou le compromission de n'importe lequel des contrôleurs peut potentiellement avoir un impact global. Implicitement le niveau global d'exposition aux risques de l'infrastructure Active Directory est ainsi devenu celui de son maillon faible à savoir le contrôleur le plus exposé ou le moins administré.
Qu'à cela ne tienne pensent déjà certains, je vais récupérer un lecteur 5"1/4 et réinstaller NT 3.1... Stop !!! Pas de gestes que vous pourriez regretter, prenez plutôt une tasse de thé (blaque contectuelle réservée aux fans de Wallace et Grommit) et regardons ensemble comme l'équipe Active Directory a pensé à vous et à ce pauvre lecteur 5"1/4 qui a bien mérité sa retraite en intégrant à Windows Server 2008 un nouveau mode d'installation des contrôleurs de domaine - le RODC.
L'objectif avec les Read-Only Domain Controler (RODC) est donc double; d'une part à réduire la surface d'exposition globale d'Active Directory et d'autre part à réduire l'impact potentiel lié à une compromission ou un vol d'un contrôleur de domaine.
Le tableau ci-dessous présente les contre-mesures proposées par le RODC pour supprimer ou diminuer l'impact des trois menaces identifiées que sont le vol d'un DC, la compromission d'un DC ou l'interception des crédentiels des Administrateurs du domaine.
Regardons maintenant de manière détaillée chacune des contre-mesures ou nouvelles fonctionnalités des RODC.
Absence de mise en cache des secrets et Read-Only Partial Attribute Set: par défaut les secrets des utilisateurs, principalement les condensés des mots de passe mais aussi d'autres informations sensibles telles que la clé de Recovery Bitlocker ne sont pas stockés sur les RODC. La liste des attributs non répliqués peut être étendue en modifiant le contenu du Patial Attribute Set (PAS). Quelques précisions supplémentaires: par défaut ne sont disponibles au sein de la base locale d'un RODC que deux condensés de mots de passe, celui du compte Administrateur local de la machine et celui du compte machine, d'autres condensés peuvent être stockés pour une durée paramétrable en fonction d'une politique de mise en cache définie de manière centralisée et suite à une authentification réalisée avec succès.
La politique permet au travers de l'appartenance à deux groupes de sécurité appelés Domain RODC Password Replication Allowed et Domain RODC Password Replication Denied de contrôler quels sont les utilisateurs pour lesquels la mise en cache est possible et quels sont ceux pour lesquels la réplication n'est pas possible. Par défaut le groupe Domain RODC Password Replication Allowed est vide et le groupe Domain RODC Password Replication Denied contient un certain nombre de groupes dont les plus importants sont Domain Admins, Entreprise Admins et Schema Admins. Enfin lorsqu'un utilisateur est authentifié via un RODC l'appartenance aux deux groupes ci-dessus est vérifiée et l'appartenance au groupe Domain RODC Password Replication Denied est prise en compte de manière prioritaire empêchant ainsi la mise en cache en cas de conflit, les deux attributs utilisés pour stocker cette politique msDS-NeverRevealedList et msDS-Reveal-OnDemandGroup confirme bien la priorité donnée à la non réplication sur le la réplication et au fait que la réplication n'est faite qu'au cas par cas (utilisateur par utilisateur et RODC par RODC) et non pas de manière globale.
La question que vous vous posez peut être à ce stade est : Comment un RODC peut-il authentifier un utilisateur s'il ne possède pas de moyen de le faire (le condensé de son mot de passe) ? Il ne peut pas !!! ce qui signifie qu'un RODC doit obligatoirement être capable de contacter de manière synchrone lors de la demande d'authentification un autre contrôleur disposant du condensé du mot de passe de l'utilisateur et c'est ce dernier qui vérifiera la validité du mot de passe et en fonction de la stratégie de mise en cache définie décidera de manière optionnelle de fournir le condensé du mot de passe au RODC. Un RODC est capable d'authentifier de manière autonome tout utilisateur pour lequel il dispose du condensé du mot de passe en cache.
Dernier point concernant la mise en cache des condensés, l'interface d'administration Active Directory Users & Computers a été enrichie de façon à permettre d'une part de connaitre à tout moment les utilisateurs ayant été authentifiés et/ou ayant leur condensé de mot de passe en cache sur un RODC, cette information sera très utile en cas de vol ou de compromission du RODC car elle permet de déclencher une réinitialisation des mots de passe ciblée et d'autre part de façon à connaitre les RODC ayant en cache le condensé du mot de passe d'un utilisateur donné. Ces informations sont stockées au sein d'Active Directory sous forme de nouveaux attributs msDS-RevealedList et msDS-AuthenticatedToAccountList.
Passons maintenant aux deux nouvelles fonctionnalités suivantes.
Base en lecture seule et réplication unidirectionnelle: En compément du contenu de la base (fichier NTDS.DIT) l'ensemble du contenu du répertoire SYSVOL ou bien encore les zones DNS lorsque celui est intégré à Active Directory, c'est ainsi l'ensemble des informations liées à active Directory qui sont en lecture seule sur un RODC de façon à se protéger contre toute modification des données locales. La mise en lecture seule est réalisée au travers d'une modification des ACLs réalisée de manière préalable à l'installation du premier RODC via la commande ADPREP /RODCPREP.
En complément à la modification des ACL conçue de façon à limiter les accès locaux ou via LDAP à de la lecture seule, la réplication entre un RODC et son partenaire de réplication est unidirectionnelle de façon à empêcher la propagation de toute modification ayant pu être réalisée localement (par exemple via modification avec un éditeur disque bas niveau ou installation d'un système parallèle), ainsi comme l'illustre la capture d'écran ci-dessous il n'y a pas d'entrée dans Replicate To de l'onglet Connection des NTDS Settings d'un RODC.
Last but not least comme disent les vice-champions du monde de Rugby (ainsi que ceux qui voudraient faire croire qu'ils ne faisaient pas que buller en cours d'anglais).
La séparation des rôles Administrateur et comptes machines spécifiques: Chaque RODC disposant de son propre compte de KDC KrbTGT cela signifie en pratique qu'un RODC est identique à un serveur membre est que la disparition d'un DC n'engendre pas de risque de compromission de ce compte particulièrement sensible, de plus il devient possible de supprimer/révoquer se compte sans impact à l'échelle du domaine autre que de ne pas pouvoir réintégrer le RODC au domaine. La possibilité de séparation des rôles Administrateur part du constant que le nombre d'administrateurs est souvent (toujours ?) trop important en particulier du fait de la confusion des rôles existant avec Windows Server 2000 et 2003 entre l'Administrateur local d'un contrôleur et l'administrateur du domaine, cette confusion étant liée à l'absence de base de compte SAM locale sur un DC. Un contrôleur de domaine Windows Server 2008 corrige donc ce défaut en supportant de nouveau la notion de base SAM locale et par tant la possibilité d'accéder à la console locale d'un RODC en s'authentifiant sur la base SAM locale en utilisant un compte pourvu de privilèges de type Administrateur (y compris appartenance aux groupes Built-In de type Backup Operators). Ce compte pourra être utilisé pour les opérations nécessitant un niveau de privilège élevé telles que l'installation de correctifs ou d'applications ou bien encore de périphériques.
La définition du groupe ou de l'utilisateur bénéficiant du privilège local Administrateur peut être faite soit lors de la pré-création du compte au sein de la MMC AD Users & Computers tels qu'illustré ci-dessous, soit localement via la commande DSMGMT "LOCAL ROLES"
Avant de conclure, quelques mots sur les pré-requis:
- le schéma doit être en version 2008 (ce qui est de toute façon obligatoire avant intégration du premier contrôleur Windows Server 2008)
- a minima un contrôleur de domaine Windows Server 2008 de type "Full" doit être installé avant de pouvoir intégrer le premier RODC (seuls les contrôleurs Windows Server 2008 peuvent prendre en compte les spécificités des RODC en terme de réplication et d'authentification
- un contrôleur de domaine existant Windows Server 2000 SP4 ou Windows Server 2003 ne peut pas être migré "in place" vers un RODC, une réinstallation complète est nécessaire
- un contrôleur de domaine existant Windows Server 2008 de type "Full" ne pourra pas être convertit en RODC sans réinstallation (et réciproquement)
J'espère vous avoir donné une meilleure vision des apports liés au RODC et comment ils permettent de mettre en oeuvre Active Directory de manière toujours plus sécurisé dans des environnements existants ou dans de nouveaux environnements où la prudence qui caractérise chacun de nous ne vous aurez même pas laissé imaginé que l'on puisse y installer un contrôleur de domaine.