Que sont les rôles FSMO ?

Dans un environnement Microsoft Active Directory (AD), tout contrôleur de domaine (DC) autorisé peut créer, modifier ou supprimer des objets de l’AD. En effet, chaque contrôleur de domaine (à l’exception de ceux en lecture seule) détient une copie accessible en écriture de la partition de son domaine. Une fois les modifications apportées, elles sont synchronisées avec les autres contrôleurs de domaine lors d’un processus appelé réplication multimaître.

Quelques opérations essentielles sont néanmoins restreintes à certains contrôleurs de domaine auxquels ont été attribués des rôles spéciaux. Ces derniers sont connus sous le nom de Flexible Single Master Operations (FSMO), ou rôles de maître d’opération. Il en existe cinq. Par défaut, lorsque vous créez un domaine Active Directory, tous les rôles FSMO sont attribués au premier contrôleur de domaine de la forêt. Si nécessaire, les administrateurs de domaine peuvent réattribuer les rôles FSMO à d’autres contrôleurs de domaine.

Demander une démo individuelle :

• Logiciel d’audit d’Active Directory de Netwrix

Objectif des rôles FSMO

Dans un environnement où il n’existe qu’un seul contrôleur de domaine (DC), la gestion de l’AD est simple : toutes les modifications d’objets sont gérées par ce DC unique. Les choses peuvent se compliquer lorsqu’il y a plusieurs contrôleurs de domaine autorisés. En effet, ils peuvent se trouver potentiellement en concurrence pour effectuer des modifications.

Dans un premier temps, Microsoft a résolu ce problème grâce à un modèle à maître unique : les droits de modification étaient réservés à un seul contrôleur de domaine, les autres DC traitant les demandes d’authentification. Toutefois, cette approche présentait une vulnérabilité évidente : si le contrôleur de domaine principal était hors ligne, aucune modification ne pouvait être apportée à l’AD tant qu’il n’était pas remis en ligne.

Pour éviter les conflits entre plusieurs contrôleurs de domaine et afin d’améliorer la résilience de l’Active Directory tout en maintenant son intégrité, Microsoft a lancé en 2003 un modèle plus synchronisé. Ce dernier intègre des rôles de maître d’opération, ou rôles FSMO, qui déterminent les responsabilités des différents contrôleurs de domaine. Ainsi, en cas de panne, un autre DC prend en charge le rôle manquant.

Que sont les cinq rôles FSMO de l’Active Directory ?

Les cinq rôles FSMO de l’Active Directory sont les suivants :

• Maître des ID relatifs (au niveau du domaine)
• Émulateur de contrôleur de domaine principal (PDC) (au niveau du domaine)
• Maître d’infrastructure (au niveau du domaine)
• Maître d’opérations des noms de domaine (au niveau de la forêt)
• Contrôleur de schéma (au niveau de la forêt)

Comme vous pouvez l’observer, les deux derniers rôles FSMO de la liste fonctionnent au niveau de la forêt : un seul DC dans la forêt peut être le détenteur du rôle. Autrement dit, chaque forêt Active Directory comprend un unique contrôleur de schéma ainsi qu’un seul maître d’opérations des noms de domaine.

En revanche, les trois autres rôles FSMO sont assumés au niveau d’un seul domaine. C’est-à-dire qu’il existe dans chaque domaine un maître d’infrastructure, un maître RID et un émulateur PDC. Dans les environnements dans lesquels il existe plusieurs domaines, chacun d’entre eux héberge ces trois rôles FSMO sur un ou plusieurs contrôleurs de domaine.

Plusieurs rôles FSMO (et même l’ensemble des rôles FSMO) peuvent être assumés par un DC unique. Le DC auquel est attribué un rôle FSMO particulier est appelé le propriétaire du rôle.

Maître des ID relatifs (RID)

Le maître des ID relatifs (RID) correspond à un rôle de niveau domaine. Dans une forêt Active Directory, il existe un maître RID sur chaque domaine. Au sein de son domaine, il est chargé d’attribuer des blocs de RID aux contrôleurs de domaine pour garantir que chaque principal de sécurité (par exemple, un utilisateur ou un groupe) dispose d’un identificateur de sécurité unique (SID).

Un SID est une chaîne alphanumérique dont la longueur peut varier. En voici un exemple :

`S-1-5-21-1234567890-1234567890-1234567890-1001`

La première partie de la chaîne correspond au SID du domaine, le même pour tous les SID d’un domaine. La dernière partie représente le RID. Il s’agit d’un nombre unique pour chaque SID du domaine. Dans l’exemple ci-dessus, 1001 est le RID attribué à un principal de sécurité concret dans le domaine.

Le maître RID attribue les blocs de RID aux contrôleurs de domaine. Ces blocs de RID se composent d’une plage consécutive de RID unique, que le contrôleur de domaine utilise pour générer un identificateur de sécurité unique (SID) lorsqu’il crée un principal de sécurité. La gestion centralisée de l’attribution des RID permet au maître RID de veiller à ce que deux contrôleurs de domaine n’allouent pas le même RID à des principaux de sécurité différents. Le caractère unique de chaque SID au sein du domaine est ainsi assuré.

Une fois qu’un bloc de RID lui est attribué par le maître RID, un contrôleur de domaine n’a plus besoin de communiquer avec ce dernier lors de la création de chaque objet AD. Toutefois, la perte du rôle de maître RID d’un domaine aboutit à l’incapacité de créer de nouveaux objets sur ce domaine, car les blocs de RID des contrôleurs de domaine sont épuisés. Dans les environnements AD avancés, cette opération prendrait beaucoup de temps, car relativement peu d’objets sont créés.

En général, le rôle de maître RID est attribué au contrôleur de domaine principal (PDC) d’un domaine, étant donné que les administrateurs lui accordent généralement une grande attention et qu’il est donc configuré pour garantir une haute disponibilité. Dans les domaines avancés, le surcoût généré par le rôle de maître RID est négligeable. Ce rôle n’est peut-être pas aussi critique que certains des autres rôles, mais il n’en reste pas moins important d’assurer la connectivité entre le maître RID et les contrôleurs de domaine.

Émulateur PDC (PDCE)

Le terme « Contrôleur de domaine principal (PDC) » remonte à l’époque de Windows NT, lorsqu’un seul contrôleur de domaine disposait d’une copie accessible en écriture de l’Active Directory. Aujourd’hui, la plupart des DC d’un domaine sont accessibles en écriture, même si un contrôleur de domaine reste encore assigné à l’émulation du rôle de PDC. Il existe un PDCE sur chaque domaine d’une forêt Active Directory.

L’émulateur de contrôleur de domaine principal est chargé des tâches suivantes :

• Synchronisation date/heure — Le PDCE est la source de temps de référence pour le domaine. Tous les postes de travail et les serveurs membres synchronisent leur heure avec celle de l’émulateur PDC. Dans une forêt multidomaines, le PDCE du domaine racine de la forêt constitue la source de temps par défaut de tous les autres émulateurs PDC de la forêt. Pour garantir la précision de la date et de l’heure sur l’ensemble de la forêt, l’émulateur PDC du domaine racine doit être configuré pour synchroniser parfaitement avec une source de temps externe fiable. La date et l’heure sont d’une importance vitale. L’authentification Kerberos constitue un bon exemple de l’importance de la synchronisation date/heure : elle échoue si la différence entre l’horloge de l’hôte qui effectue la requête et celle du contrôleur de domaine responsable de l’authentification dépasse le maximum spécifié (par défaut, 5 minutes), ce qui permet de contrer certaines activités malveillantes, comme les attaques par rejeu.
• Modification du mot de passe et authentification — Lorsque le mot de passe d’un utilisateur est modifié, la modification est d’abord effectuée sur le DC qui a authentifié l’utilisateur. Cette mise à jour du mot de passe est immédiatement répliquée sur le PDCE du domaine. Si un compte essaie de s’authentifier auprès d’un contrôleur de domaine qui n’a pas encore reçu une modification de mot de passe récente (en attente de la prochaine réplication planifiée), la requête est transférée au PDCE du domaine. Ce dernier traite la demande d’authentification et indique au contrôleur de domaine qui effectue la requête soit de l’accepter soit de la rejeter. Ce comportement garantit que les mots de passe peuvent être traités de manière fiable même si de récentes modifications n’ont pas encore été totalement propagées lors de la réplication planifiée.
• Statut de verrouillage du compte — De la même manière, si un compte est verrouillé à la suite de plusieurs tentatives de connexion infructueuses, le PDCE traite immédiatement ce verrouillage, qui est répliqué sur l’ensemble des DC du domaine afin de garantir qu’un compte verrouillé ne puisse pas se connecter à un autre contrôleur de domaine. Lorsqu’un compte est déverrouillé par un administrateur, cette modification est immédiatement répliquée dans le domaine.
• Mises à jour des stratégies de groupe — Si des mises à jour sont apportées à un objet de stratégie de groupe (GPO), elles sont validées dans un premier temps par le contrôleur de domaine qui détient le rôle PDCE. Cela évite les conflits de version qui pourraient se produire si un GPO venait à être modifié sur deux contrôleurs de domaine dans un intervalle de temps rapproché.
• Compatibilité descendante — Dans les organisations qui utilisent encore des périphériques ou des logiciels d’ancienne génération fonctionnant sous Windows NT, le PDCE peut faire office de contrôleur de domaine principal. Autrement dit, jouer le rôle de maître explorateur : recueillir et partager des informations sur les applications et les appareils d’un réseau.
• Système de fichiers distribués (DFS) — Par défaut, les serveurs racines d’un système de fichiers distribués (DFS) effectuent régulièrement une demande de mise à jour des informations de l’espace de noms DFS au PDCE. Ce comportement peut nécessiter de nombreuses ressources, mais l’activation du paramètre RootScalability Dfsutil.exe permet aux serveurs racines DFS de demander une mise à jour auprès du contrôleur de domaine le plus proche.

Le rôle d’émulateur PDC devrait être attribué à un contrôleur de domaine hautement accessible, disposant de connexions rapides et offrant des performances élevées. En effet, la perte du contrôleur de domaine qui héberge ce rôle est susceptible d’avoir un impact immédiat et significatif sur les opérations système.

Maître d’infrastructure

Le maître d’infrastructure correspond à un rôle de niveau domaine. Il a pour fonction principale la gestion des références d’objets interdomaines dans une forêt multidomaines. Dans une même forêt, le maître d’infrastructure compare les objets de son domaine à ceux des autres domaines, et les synchronise avec les serveurs de catalogue global.

Dans certains cas, ces opérations ne sont pas nécessaires. Par exemple, dans les environnements dans lesquels il n’y a qu’un seul domaine AD, la gestion des références interdomaines est évidemment inutile. De la même manière, si tous les contrôleurs de domaine d’un même domaine hébergent le catalogue global (ce qui est assez courant aujourd’hui grâce à l’amélioration de la bande passante du réseau), ils disposeront tous d’informations à jour sans dépendre du maître d’infrastructure.

Les principales fonctions du maître d’infrastructure sont les suivantes :

• Références d’objets interdomaines — Dans une forêt multidomaines, les objets d’un domaine peuvent être référencés dans un autre domaine. On peut citer en exemple le cas d’un utilisateur qui appartient à un domaine, et que l’on ajoute à un groupe de sécurité d’un domaine différent. Dans ce cas de figure, un espace réservé (appelé « objet fantôme ») est créé dans le domaine du groupe pour faire référence à l’utilisateur de l’autre domaine. Les objets fantômes sont des objets utilisés pour le suivi et la gestion des liens permanents vers des objets supprimés et des attributs de liaison qui font référence à des objets appartenant à un autre domaine au sein de la forêt.

• Mise à jour des références d’objets entre groupes et utilisateurs — Le maître d’infrastructure est chargé de la mise à jour du SID et du nom unique (DN) d’un objet dans une référence d’objet interdomaine. Il traduit également les GUID, SID et DN en noms entre les domaines d’une forêt.

• Nettoyage des objets obsolètes — Le maître d’infrastructure vérifie régulièrement si son domaine contient des objets qui ne sont plus valides (tels que des objets provenant de relations d’approbation qui n’existent plus) et les supprime.

Si un contrôleur de domaine qui détient le rôle de maître d’infrastructure tombe en panne, l’impact reste principalement administratif. En effet, cette panne entraîne l’échec de la résolution des noms d’objets interdomaines, mais les appartenances à des groupes interdomaines continueront à fonctionner.

Maître d’opérations des noms de domaine

Le maître d’opérations des noms de domaine correspond à un rôle de niveau entreprise. Il n’en existe qu’un seul dans une forêt Active Directory. Il s’agit de l’unique contrôleur de domaine qui peut ajouter de nouveaux domaines et de nouvelles partitions d’application dans une forêt Active Directory.

Le rôle de maître d’opérations des noms de domaine n’entraîne pas un surcoût élevé et sa perte n’a qu’un impact limité, voire nul, sur les opérations système. En effet, l’ajout et la suppression de domaines ou de partitions ne sont pas effectués fréquemment et sont rarement des opérations prioritaires.

Contrôleur de schéma

Il s’agit d’un rôle FSMO de niveau entreprise. Il ne peut donc y avoir qu’un seul contrôleur de schéma dans une forêt Active Directory. Le schéma définit les classes d’objets (c’est-à-dire les types d’objets, par exemple les utilisateurs, les groupes et les ordinateurs) et leurs attributs qui peuvent exister dans la base de données AD. Le schéma doit parfois être modifié, notamment pour ajouter un nouveau type d’objet ou un nouvel attribut. Pour éviter tout chevauchement ou conflit de mises à jour, seul le contrôleur de domaine qui détient le rôle de contrôleur de schéma peut effectuer des modifications au schéma AD. À chaque mise à jour du schéma, le contrôleur de schéma assure la réplication de toutes les modifications sur l’ensemble des contrôleurs de domaine de la forêt.

Le contrôleur de schéma doit être disponible pour toute mise à jour. Les modifications de schéma sont néanmoins relativement peu fréquentes dans la plupart des environnements. Parmi les situations susceptibles d’entraîner la mise à jour du schéma, on peut citer la mise à niveau de l’Active Directory, l’intégration de certains types de logiciels d’entreprise, l’élévation du niveau fonctionnel de la forêt, ou encore la mise à niveau du système d’exploitation d’un contrôleur de domaine vers une version plus récente que celle de la forêt.

Téléchargez le guide gratuit :

• Meilleures pratiques de sécurité de l’Active Directory

Identification des propriétaires des rôles FSMO

Savoir quels sont les contrôleurs de domaine au sein de votre environnement AD qui hébergent les cinq rôles FSMO revêt une grande importance. Pour y parvenir, il existe plusieurs manières.

Utilisation de l’invite de commandes

Exécutez la commande suivante pour savoir rapidement quels sont les contrôleurs de domaine qui détiennent les rôles FSMO :

netdom query fsmo /domain:<DomainName>

Utilisation de PowerShell

Une autre option consiste à exécuter ce script PowerShell :

(Get-ADForest).Domains |

ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `

Select-Object Domain, HostName, OperationMasterRoles

Utilisation des outils de l’Active Directory

Trouvez les contrôleurs de domaine qui détiennent les trois rôles FSMO de niveau domaine en utilisant la console Utilisateurs et ordinateurs Active Directory (ADUC). Effectuez d’abord un clic droit sur votre domaine et cliquez ensuite sur Maîtres d’opérations, comme indiqué ci-dessous :

Cliquez ensuite sur chaque onglet pour voir le contrôleur de domaine correspondant :

Pour savoir quel DC détient le rôle de maître d’opérations des noms de domaine, effectuez un clic droit sur Domaines et approbations Active Directory, et cliquez ensuite sur Maîtres d’opérations, comme indiqué ci-dessous.

Une fenêtre contextuelle s’ouvre et permet d’identifier le titulaire actuel du rôle :

Pour identifier le contrôleur de domaine qui détient le rôle FSMO de contrôleur de schéma, vous pouvez utiliser le composant logiciel enfichable Schéma Active Directory. Par défaut, ce dernier n’est néanmoins pas visible sous Windows Server. Avant de pouvoir l’utiliser, vous devez donc suivre les étapes suivantes :

• Cliquez sur Démarrer, puis sur Exécuter, et tapez regsvr 32 schmmgmt.dll dans le champ Ouvrir, comme indiqué ci-dessous. Cliquez ensuite sur OK.

• Dans le menu Fichier de la console, cliquez sur Ajouter/Supprimer un composant logiciel enfichable, cliquez sur Ajouter, double-cliquez sur Schéma Active Directory, ensuite sur Fermer, puis sur OK.

Vous avez alors accès au composant logiciel enfichable schéma Active Directory. Pour afficher le serveur qui détient le rôle de contrôleur de schéma, ouvrez le composant logiciel enfichable, effectuez un clic droit sur Schéma Active Directory dans le volet supérieur gauche, puis cliquez sur Maîtres d’opérations. La capture d’écran ci-dessous affiche le résultat obtenu :

Transfert et saisie des rôles FSMO

Dans l’Active Directory, les rôles FSMO sont attribués automatiquement lors de la création d’un domaine ou d’une forêt AD, mais les administrateurs de domaine et d’entreprise ont néanmoins la possibilité de transférer ces rôles d’un contrôleur de domaine à un autre, s’ils le souhaitent. Toutefois, n’oubliez pas que pour transférer un rôle FSMO, le détenteur actuel du rôle et le DC cible doivent tous deux être en ligne et connectés au réseau.

Si le titulaire actuel n’est pas disponible et ne peut pas être rétabli, le rôle FSMO doit être attribué à un administrateur de domaine ou d’entreprise.

Il est recommandé de documenter le transfert ou la saisie des rôles FSMO.

Comment Netwrix peut vous aider

Comme nous l’avons vu dans cet article, les rôles FSMO sont importants pour la continuité des activités d’une entreprise et sa sécurité. Il est donc essentiel d’auditer toutes leurs modifications. Netwrix Auditor for Active Directory automatise cet audit et vous alerte en cas de modifications suspectes afin que vous puissiez intervenir rapidement et éviter ainsi l’arrêt de vos activités ou une violation de données.

Bien entendu, la protection des rôles FSMO ne représente qu’un élément parmi d’autres d’une stratégie de sécurité. Netwrix Auditor for Active Directory vous offre une visibilité totale et un contrôle complet sur vos systèmes critiques. Cet outil surveille et analyse en permanence les modifications et les changements au sein de l’Active Directory, ainsi que toute autre activité, afin de détecter des menaces émergentes et vous permettre d’y répondre rapidement et de manière efficace. Vous limitez ainsi leur impact sur les processus d’entreprise, la productivité des utilisateurs et la sécurité.