La Partie 6 de cette série de blogs sur l'Active Directory Domain Services (AD DS) est consacrée aux rôles FSMO (Flexible Single Master Operation). Le modèle FSMO dans l'AD vous permet d'éviter les scénarios conflictuels du type de ceux que nous avons envisagés ci-dessus.
Les rôles FSMO sont un ensemble de services et de processus, qui sont gérés par les DC dans une configuration AD multi-modèle. Ces rôles assurent le bon fonctionnement de toutes les capacités de l'AD, y compris la réplication AD en temps voulu et la cohérence des informations AD dans l'ensemble de la forêt AD dans toute entreprise.
L'histoire des rôles FSMO
Lorsque Microsoft a introduit l'AD dans l'édition Windows 2000 et que les entreprises ont commencé à adopter les services AD comme leur service d'annuaire préféré, la création de plusieurs domaines AD avec des contrôleurs de domaine (DC) dans chaque domaine a entraîné une multitude de défis logistiques. C'était avant l'adoption du modèle FSMO.
Plusieurs DC tentaient d'authentifier et de traiter les mêmes demandes au sein de chaque domaine. Chaque DC du site AD défini ne disposait pas d'un processus clair pour déterminer s'il devait être choisi pour le processus d'authentification et de modification ultérieur. De ce fait, des situations conflictuelles se produisaient, telles que des erreurs d'authentification et des réplications erronées.
Ces problèmes exigeaient une nouvelle solution, et Microsoft l'a fournie.
Le modèle single-master qui a été introduit a fait en sorte qu'un DC, ou le DC maître, soit uniquement responsable du traitement des demandes de modification dans chaque domaine, tandis que les autres DC étaient uniquement responsables des authentifications. Bien que cette nouvelle fonctionnalité ait permis de mieux gérer les demandes de changement et les conflits, il existait toujours des scénarios où le fonctionnement continu et sans faille de l'AD était affecté. Par exemple, lorsque le DC maître était en panne et incapable de traiter les demandes, des retards se produisaient dans les modifications qui devaient être apportées aux objets AD.
Il y avait également le concept du last writer wins, conçu comme un mécanisme intégré de résolution des conflits dans l'AD. Il garantit que les modifications apportées aux données AD par le dernier DC qui les traite sont considérées comme valides. Mais le modèle single-master de prévention des conflits de réplication était difficile à contrôler. Toutes les données AD étant confinées à un seul domaine, sans regroupement d'objets et sans relations de confiance transitives définies pour les domaines de la forêt AD, le suivi des modifications était difficile.
Et donc...
Le FSMO, qui est un modèle multi-master, a vu le jour en 2003. Et il est encore utilisé aujourd'hui.
Dans ce modèle, les rôles détenus par tout DC sont transférables ou distribués. Si un DC responsable du traitement d'une demande de service et de changement est hors ligne ou injoignable, et que par conséquent le DC n'est pas en mesure de la traiter, les autres DC peuvent intervenir pour assurer la continuité et l'exécution des demandes en temps voulu. C'est l'essence même du mécanisme multi-modèle ou des rôles FSMO dans l'AD.
Une immersion en détail dans le FSMO maintenant...
Il existe cinq rôles FSMO que nous devons connaître. Certains de ces rôles FSMO sont applicables à l'ensemble de la forêt, tandis que d'autres ne sont applicables qu'au domaine. (Voir le tableau 1).
| Rôles FSMO ayant une portée à l'échelle de la forêt |
Rôles FSMO ayant une portée à l'échelle du domaine |
|
Maître du schéma |
Maître des ID relatifs ou RID |
|
Maître des noms de domaine |
Contrôleur de domaine primaire ou émulateur PDC |
|
|
Maître de l'infrastructure |
Tableau 1. Rôles FSMO et leur champ d'application
Maître du schéma
➤ Ce rôle est attribué à un seul DC dans l'ensemble de la forêt AD.
➤ Il traite et gère les modifications à apporter aux données du schéma AD, ou à la partition du schéma, qui sont essentiellement les modifications apportées à la définition des objets AD et à leurs attributs associés.
➤ Une fois que les modifications ont été effectuées par ce DC désigné, la réplication AD garantit que tous les autres DC de la forêt disposent de ces données mises à jour.
Maître des noms de domaine
➤ Lorsque la partition de configuration AD doit être modifiée, le DC désigné ayant le rôle de maître des noms de domaine est contacté. Cela inclut les cas où des domaines supplémentaires doivent être créés ou supprimés au sein de la forêt AD.
➤ Ce rôle garantit que tous les domaines créés au sein de la forêt sont identifiables de manière unique. Il accepte les noms de domaine avec des noms NetBIOS uniques, afin de garantir qu'aucun conflit de dénomination ne survient dans l'espace de noms de domaine.
➤ Ce DC est également utilisé lorsque et si la partition d'application doit être modifiée, c'est-à-dire si un serveur DNS doit être ajouté dans les domaines en cours de création.
➤ Ce rôle est également utilisé pour se connecter à d'autres services d'annuaire externes en dehors des services AD Microsoft, le cas échéant.
Maître des ID relatifs ou RID
➤ Ce rôle est attribué à un seul DC dans chaque domaine, et est responsable de l'attribution de blocs d'identifiants de sécurité ou SID, à chaque DC. Ceci, à son tour, assure l'attribution d'identifiants uniques appelés ID relatifs ou RID, pour chaque objet principal de sécurité qui est créé dans chaque domaine.
➤ Ce rôle de DC traite la demande faite par d'autres DC du domaine, et attribue des blocs RID au DC demandeur. Ce pool RID constitue la réponse du maître RID aux demandes de changement qu'il reçoit des autres DC.
➤ Ce rôle gère également la modification des données AD lorsque les objets AD sont déplacés entre les domaines.
Émulateur PDC
➤ Le maintien de la cohérence entre toutes les ressources connectées est crucial pour une réplication AD efficace et opportune. Le DC doté du rôle d'émulateur PDC assure cette cohérence.
➤ En outre, le DC avec ce rôle est le DC faisant autorité pour traiter toutes les instances de verrouillage de compte afin de garantir une sécurité intégrée pour les services AD et d'autres demandes de changement de mot de passe en cas de non-vérification dans un DC individuel.
➤ La gestion de la stratégie de groupe est également autorisée par le DC émulateur PDC.
Maître de l'infrastructure
➤ Ce rôle prend de l'importance dans les environnements multi-domaines lorsque les objets de chaque domaine sont référencés par un autre domaine.
➤ Le GUID (Globally Unique Identifier), le SID (Security Identifier) et le DN (Distinguished Names), sont mis à jour et maintenus par le DC ayant ce rôle, afin de garantir que les références croisées entre les domaines se produisent de manière transparente.
➤ Ce rôle travaille en étroite collaboration avec le serveur de catalogue global pour maintenir des informations mises à jour sur l'ensemble du domaine et contribue à une résolution de noms sans erreur lors du référencement croisé des objets AD entre les domaines.
Comprendre les différents rôles que les DC peuvent endosser, permet d'assimiler les concepts des opérations AD.
Une connaissance approfondie de l'AD devrait vous aider à examiner et à apprécier la manière dont la sécurité peut et doit être assurée en permanence dans toute infrastructure AD. Cela permet également de mieux comprendre comment atténuer les risques pour la sécurité de la configuration AD. Dans la Partie 7 de cette série de blogs, nous examinerons comment l'AD peut être conçu pour la sécurité et nous étudierons également en détail les concepts de l'AD et de cybersécurité.