Les nouveaux utilisateurs créés sur un contrôleur de domaine (DC) d’un environnement Active Directory (AD) sont-ils parfois supprimés par erreur après quelques minutes seulement par les DC d’autres sites au sein d’une forêt AD ?
Les modifications apportées dans un site AD particulier sont-elles parfois réécrites par les DC d’autres sites ? Les objets AD peuvent-ils être identifiés par erreur ?
Plus d’un compte utilisateur AD, par exemple, avec tous ses attributs associés, peut-il être la réplique d’un autre compte utilisateur ?
De tels scénarios conflictuels se produisent-ils dans une configuration AD qui fonctionne bien ?
Avec les questions ci-dessus à l’esprit, creusons un peu plus.
La sixième partie de cette série de blogs sur les services de domaine Active Directory (AD DS) est consacrée aux rôles FSMO (Flexible Single Master Operation). Le modèle FSMO dans 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 d’AD, y compris la réplication d’AD en temps voulu et la cohérence des informations d’AD dans l’ensemble de la forêt d’AD de toute organisation.
L’histoire des rôles FSMO
Lorsque Microsoft a introduit AD dans l’édition Windows 2000 et que les organisations 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 à maître unique 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 d’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 aussi le concept du dernier écrivain victorieux, conçu comme un mécanisme intégré de résolution des conflits dans 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 à maître unique de prévention des conflits de réplication était difficile à contrôler. Avec toutes les données AD confinées dans un seul domaine, sans regroupement d’objets et sans relations de confiance transitives définies pour les domaines dans la forêt AD, le suivi des modifications était difficile.
Et donc…
Le FSMO, qui est un modèle multi-maître, a vu le jour en 2003. Et il est toujours 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 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 applicables à l’ensemble de la forêt |
Rôles FSMO applicables à l’ensemble du domaine |
| Maître du schéma | ID relatif ou maître RID |
| Maître d’opérations des noms de domaine | Contrôleur de domaine primaire ou émulateur PDC |
| Maître de l’infrastructure |
Tableau 1. Rôles du FSMO et leur champ d’application
Maître des schémas
➤ 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 de 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 d’opérations des noms de domaine
➤ Lorsque la partition de configuration d’AD doit être modifiée, le DC désigné ayant le rôle de Maître d’opérations 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 de Microsoft, le cas échéant.
ID relatif ou maître 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 de RID au DC demandeur. Ce pool de 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 de 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 politique de groupe est également autorisée par le DC émulateur de 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.
➤ L’identifiant unique global ou GUID, l’identifiant de sécurité ou SID et les noms distingués ou DN, 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 nom 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 d’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 septième partie de cette série de blogs, nous examinerons comment AD peut être conçu pour la sécurité et nous étudierons également en détail les concepts d’AD et de cybersécurité.
Source : A practical approach to Active Directory Domain Services, Part 6: FSMO roles in AD
