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

Lorsqu’un objet est créé, mis à jour ou supprimé, l’Active Directory (AD) permet la validation de l’action par n’importe quel contrôleur de domaine (DC) autorisé. Cette validation est rendue possible car chaque contrôleur de domaine (à l’exception de ceux en lecture seule) conserve une copie accessible en écriture de la partition de son propre domaine. Lorsqu’une modification a été validée, elle est automatiquement répliquée sur d’autres contrôleurs de domaine : il s’agit d’un processus appelé réplication multimaître. Ce comportement permet le traitement de la majorité des opérations système de manière fiable par différents contrôleurs de domaine et assure des niveaux élevés de redondance, de disponibilité et d’accessibilité dans l’Active Directory.

Sélection de contenu connexe :

• [E-book gratuit] Qu’est-ce que l’Active Directory ?

Certaines opérations sont toutefois plus sensibles que d’autres et font figure d’exceptions : leur exécution est limitée à un contrôleur de domaine particulier. Pour répondre à cette situation, l’Active Directory utilise un ensemble de rôles spécifiques. Microsoft y fait référence sous le nom de rôles de maître d’opérations, mais le plus souvent ils sont désignés par leur nom original : rôles d’opérations à maître unique flottant (FSMO).

Que sont les rôles FSMO ?

Les cinq rôles FSMO

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

• Contrôleur de schéma
• Maître d’opérations des noms de domaine
• Maître d’infrastructure
• Maître des ID relatifs (RID)
• Émulateur PDC

Chaque forêt comprend un unique contrôleur de schéma ainsi qu’un seul maître d’opérations des noms de domaine. Il existe dans chaque domaine un maître d’infrastructure, un maître RID et un émulateur PDC. Un seul contrôleur de domaine peut remplir les fonctions de chaque rôle à un moment donné. Pour cette raison, un unique contrôleur de domaine peut assumer tous les rôles FSMO, mais il ne peut pas y avoir plus de cinq serveurs dans un environnement à domaine unique qui assument ces rôles.

S’il y a des domaines supplémentaires, chacun d’entre eux contiendra son propre maître d’infrastructure, son propre maître RID et son propre émulateur PDC. Lorsqu’un nouveau domaine est ajouté à une forêt, seuls ces trois rôles FSMO de niveau domaine sont assignés au contrôleur de domaine initial. Les deux rôles FSMO de niveau entreprise (contrôleur de schéma et maître d’opérations des noms de domaine) existent déjà dans le domaine racine de forêt.

Contrôleur de schéma

Il s’agit d’un rôle FSMO de niveau entreprise. Il ne peut y avoir qu’un seul contrôleur de schéma dans une forêt Active Directory.

Le propriétaire du rôle est le seul contrôleur de domaine d’une forêt Active Directory qui comprend une partition de schéma accessible en écriture. En conséquence, le DC qui héberge le rôle FSMO de contrôleur de schéma doit être disponible pour modifier le schéma de la forêt. Parmi les exemples d’actions qui entraînent la mise à jour du schéma, on peut citer l’élévation du niveau fonctionnel de la forêt et 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.

Le rôle de contrôleur de schéma 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, à moins que des modifications du schéma soient nécessaires, ce rôle peut rester hors ligne de manière indéfinie sans réelles conséquences. Il faut néanmoins saisir le rôle de contrôleur de schéma lorsque le contrôleur de domaine qui l’héberge ne peut pas être remis en ligne. Remettre ensuite le rôle de contrôleur de schéma en ligne une fois qu’il a été saisi peut entraîner des problèmes d’incohérence et d’intégrité des données graves dans la forêt.

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

Il s’agit d’un rôle de niveau entreprise. Il n’existe qu’un seul maître d’opérations des noms de domaine dans une forêt Active Directory.

Le propriétaire du rôle est l’unique contrôleur de domaine d’une forêt Active Directory qui peut ajouter de nouveaux domaines et de nouvelles partitions d’application à la forêt. Il doit également être disponible pour leur suppression.

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. Par conséquent, il est recommandé de saisir le rôle de maître d’opérations des noms de domaine uniquement lorsque le contrôleur de domaine qui l’héberge ne peut pas être remis en ligne.

Maître des ID relatifs (RID)

Il s’agit d’un rôle de niveau domaine. Dans une forêt Active Directory, il existe un maître RID sur chaque domaine.

Le propriétaire du rôle de maître RID est responsable de l’allocation sur son domaine de blocs d’identificateur relatifs (RID) aux contrôleurs de domaine. Les blocs de RID se composent d’une plage consécutive de RID unique, utilisée lors de la création d’un objet pour générer son identificateur de sécurité unique (SID). Le maître RID est également chargé de déplacer les objets d’un domaine à un autre dans une forêt.

Dans les domaines avancés, le surcoût généré par le maître RID est négligeable. Étant donné que les administrateurs accordent généralement une grande attention au contrôleur de domaine principal (PDC) d’un domaine, ne pas transférer le rôle assigné au PDC du domaine permet d’assurer sa disponibilité. Il est également important de veiller à ce que les contrôleurs de domaine, existants ou récemment promus, en particulier ceux promus sur des sites distants ou intermédiaires, disposent d’une connectivité réseau pour pouvoir contacter le maître RID et obtenir de manière fiable des blocs de RID.

La perte du rôle de maître RID d’un domaine finit par entraîner l’incapacité de créer de nouveaux objets sur ce domaine, car les blocs de RID des contrôleurs de domaine restants sont épuisés. On pourrait penser que l’indisponibilité du contrôleur de domaine qui détient le rôle de maître RID est susceptible d’entraîner des perturbations opérationnelles, mais ce n’est pas le cas. Dans les environnements avancés, l’impact est généralement facilement supportable pendant de longues périodes en raison du volume relativement faible d’événements de création d’objets. Remettre en ligne le contrôleur de domaine qui détenait le rôle de maître RID après avoir pris possession de son rôle peut introduire des identificateurs dupliqués sur le domaine. C’est pourquoi ce rôle ne doit être pris que si le contrôleur de domaine qui l’héberge ne peut pas être remis en ligne.

Maître d’infrastructure

Il s’agit d’un rôle de niveau domaine. Il y a un maître d’infrastructure sur chaque domaine d’une forêt Active Directory.

Le maître d’infrastructure synchronise les objets avec les serveurs de catalogue global. Il effectue une comparaison de ses données avec celles du serveur de catalogue global, qui lui transmet les données non présentes dans sa base de données. Si tous les contrôleurs de domaine d’un domaine précis sont également des serveurs de catalogue global, ils disposeront alors de toutes les informations à jour (à condition que la réplication fonctionne sans erreurs). Dans ce cas-là, le détenteur du rôle de maître d’infrastructure n’est pas important puisqu’il n’a en réalité aucune tâche à effectuer.

Le propriétaire du rôle de maître d’infrastructure est également responsable de la gestion des objets fantômes. Il s’agit d’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 (p. ex., un groupe de sécurité de domaine local dont l’un des utilisateurs membres fait partie d’un domaine différent).

Le maître d’infrastructure peut être placé sur n’importe quel contrôleur de domaine à moins que la forêt Active Directory comprenne des contrôleurs de domaine qui n’hébergent pas le catalogue global. Dans ce dernier cas, c’est sur l’un de ces contrôleurs de domaine que doit être placé le maître d’infrastructure.

Seuls les administrateurs sont susceptibles de se rendre compte de la perte du contrôleur de domaine qui détenait le rôle de maître d’infrastructure, dont les conséquences sont acceptables pendant une période prolongée. Cette perte entraîne l’échec de la résolution des noms de liens d’objets interdomaines, mais n’a pas d’impact sur la capacité d’exploiter les appartenances aux groupes de plusieurs domaines.

Sélection de contenu connexe :

• [Guide gratuit] Meilleures pratiques de gestion des groupes de l’Active Directory

Émulateur PDC

L’émulateur de contrôleur de domaine principal (émulateur PDC ou PDCE) est un rôle de niveau domaine. Il existe un PDCE sur chaque domaine d’une forêt Active Directory.

Il contrôle l’authentification au sein d’un domaine, qu’il s’effectue à l’aide du protocole Kerberos v5 ou NTLM. Lorsqu’un utilisateur change son mot de passe, cette modification est traitée par l’émulateur PDC.

Le détenteur du rôle PDCE est responsable de différentes opérations essentielles :

• Compatibilité descendante. Le PDCE imite le comportement de maître unique d’un contrôleur de domaine principal Windows NT. Pour résoudre les problèmes de compatibilité descendante, le PDCE s’enregistre comme un contrôleur de domaine cible pour les applications héritées qui effectuent des opérations accessibles en écriture et pour certains outils d’administration qui ignorent le comportement multimaître des DC de l’Active Directory.
• Synchronisation date/heure. Chaque PDCE est utilisé comme une source de temps maître au sein de son domaine. Le PDCE du domaine racine de forêt fait office de serveur par défaut du protocole de temps du réseau (NTP) de la forêt. Le PDCE présent dans tous les autres domaines au sein d’une forêt synchronise son horloge avec celle du PDCE de la forêt racine. Les contrôleurs de domaine non PDCE synchronisent leurs horloges avec celle du PDCE de leur domaine. Les hôtes joints à un domaine synchronisent leurs horloges avec celle de leur contrôleur de domaine par défaut. 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.
• Traitement de la mise à jour du mot de passe. Lorsque les mots de passe de l’ordinateur et de l’utilisateur sont modifiés ou réinitialisés par un contrôleur de domaine non PDCE, la modification validée 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. Le PDCE est également responsable du traitement des verrouillages de compte. En effet, toutes les authentifications par mot de passe échouées sont transmises au PDCE.
• Mises à jour des stratégies de groupe. Toutes les mises à jour d’objet de stratégie de groupe (GPO) sont validées par le PDCE du domaine. Cela évite les conflits de version qui pourraient se produire si un GPO était modifié sur deux contrôleurs de domaine à peu près au même moment.
• Système de fichiers distribués. 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. Bien que ce comportement puisse nécessiter de nombreuses ressources, 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 PDCE doit être placé sur un contrôleur de domaine hautement accessible, disposant de connexions rapides et offrant des performances élevées. Par ailleurs, l’émulateur PDC du domaine racine de forêt doit être configuré à l’aide d’une source de temps externe fiable.

On peut s’attendre à ce que la perte du contrôleur de domaine qui héberge le rôle d’émulateur PDC ait un impact immédiat et significatif sur les opérations système. En revanche, prendre possession du rôle PDCE n’a que très peu de conséquences pour le domaine par rapport aux autres rôles. Il s’agit d’ailleurs d’une bonne pratique recommandée lorsque le contrôleur de domaine qui détient ce rôle n’est plus accessible en raison d’une non-disponibilité imprévue.

Identification des propriétaires de rôle

Pour identifier les propriétaires de rôle FSMO, vous pouvez soit utiliser une invite de commandes soit PowerShell.

Invite de commandes

netdom query fsmo /domain:<DomainName>

PowerShell

(Get-ADForest).Domains | `
ForEach-Object{ Get-ADDomainController -Server $_ -Filter {OperationMasterRoles -like "*"}} | `
Select-Object Domain, HostName, OperationMasterRoles

Transfert des rôles FSMO

La plupart du temps, les rôles FSMO restent assignés à leurs contrôleurs de domaine d’origine, mais ils peuvent néanmoins être transférés, au besoin. Les rôles FSMO ne sont pas des rôles inutiles : ils sont nécessaires pour certaines opérations importantes. Il peut donc être souhaitable et même parfois obligatoire de les déplacer d’un contrôleur de domaine à un autre.

Rétrograder le contrôleur de domaine propriétaire du rôle constitue l’une des méthodes pour leur transfert, mais ce n’est pas la meilleure des approches. Lorsqu’un DC est rétrogadré, il essaie de transférer tous les rôles FMSO qu’il héberge vers des contrôleurs de domaine appropriés dans la forêt. Les rôles de niveau domaine peuvent uniquement être transférés vers des contrôleurs de domaine du même domaine, mais ceux de niveau entreprise peuvent être transférés vers n’importe quel contrôleur de domaine approprié de la forêt. Bien qu’il existe des règles qui encadrent le processus de transfert des rôles FSMO du contrôleur de domaine rétrogradé, il est impossible de contrôler directement où ils seront transférés.

La meilleure méthode pour déplacer un rôle FSMO est de le transférer manuellement en utilisant la console de gestion, PowerShell ou l’outil de maintenance ntdsutil.exe. Pendant ce transfert manuel, le contrôleur de domaine source synchronise avec le contrôleur de domaine cible avant de transférer le rôle.

Pour transférer un rôle FSMO, un compte doit bénéficier des privilèges suivants :

Comment transférer des rôles FSMO à l’aide de la console de gestion

Transférer le rôle de contrôleur de schéma

Le rôle de contrôleur de schéma peut être transféré à l’aide du composant logiciel enfichable de gestion Schéma Active Directory.

S’il ne fait partie des composants de la console de gestion, il devra être enregistré. Pour ce faire, ouvrez une invite de commandes avec élévation de privilèges et entrez la commande regsvr32 schmmgmt.dll.

Une fois la DLL enregistrée, exécutez la console de gestion en tant que membre utilisateur du groupe Administrateurs et ajoutez le composant logiciel enfichable Schéma Active Directory :

Effectuez un clic droit sur le nœud Schéma Active Directory, puis sélectionnez Changer le contrôleur de domaine Active Directory. Choisissez le contrôleur de domaine vers lequel le rôle FSMO de contrôleur de schéma sera transféré et cliquez sur OK pour lier le composant logiciel enfichable Schéma Active Directory au contrôleur de domaine. (Un avertissement peut s’afficher et indiquer que le composant ne peut pas modifier le schéma, car il n’est pas connecté au contrôleur de schéma.)

Effectuez un clic droit sur le nœud Schéma Active Directory, puis sélectionnez Maître d’opérations. Cliquez ensuite sur le bouton Modifier pour commencer le transfert du rôle de contrôleur de schéma vers le contrôleur de domaine spécifié :

Transférer le rôle de maître d’opérations des noms de domaine

Le rôle de maître d’opérations des noms de domaine peut être transféré à l’aide du composant logiciel enfichable Domaines et approbations Active Directory de la console de gestion.

Exécutez la console de gestion en tant qu’utilisateur membre du groupe Administrateurs de l’entreprise et ajoutez le composant logiciel enfichable Domaines et approbations Active Directory à la console de gestion :

Effectuez un clic droit sur le nœud Domaines et approbations Active Directory, puis sélectionnez Changer le contrôleur de domaine Active Directory. Choisissez le contrôleur de domaine vers lequel le rôle FSMO de maître d’opérations des noms de domaine sera transféré et cliquez sur OK pour lier le composant logiciel enfichable Domaines et approbations Active Directory au contrôleur de domaine.

Effectuez un clic droit sur le nœud Domaines et approbations Active Directory, puis sélectionnez Maître d’opérations. Cliquez ensuite sur le bouton Modifier pour commencer le transfert du rôle de maître d’opérations des noms de domaine vers le contrôleur de domaine spécifié :

Transférer les rôles de maître RID, maître d’infrastructure et d’émulateur PDC

Les rôles de maître RID, de maître d’infrastructure et d’émulateur PDC peuvent être transférés à l’aide du composant logiciel enfichable Utilisateurs et ordinateurs Active Directory de la console de gestion.

Exécutez la console de gestion en tant qu’utilisateur membre du groupe Administrateurs de domaines au sein du domaine vers lequel les rôles sont transférés, et ajoutez le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory à la console de gestion :

Effectuez un clic droit soit sur le nœud Domaine soit sur le nœud Utilisateurs et ordinateurs Active Directory, puis sélectionnez Changer le contrôleur de domaine Active Directory. Choisissez le contrôleur de domaine vers lequel le rôle FSMO sera transféré et cliquez sur le bouton OK pour lier le composant logiciel enfichable Utilisateurs et ordinateurs Active Directory au contrôleur de domaine.

Effectuez un clic droit sur le nœud Utilisateurs et ordinateurs Active Directory, puis cliquez sur Maîtres d’opérations. Sélectionnez ensuite l’onglet approprié et cliquez sur Modifier pour commencer le transfert du rôle FSMO vers le contrôleur de domaine spécifié :

Comment transférer des rôles FSMO à l’aide de PowerShell

Vous pouvez transférer des rôles FSMO à l’aide de la cmdlet PowerShell suivante :

Move-ADDirectoryServerOperationMasterRole -Identity TargetDC -OperationMasterRole pdcemulator, ridmaster, infrastructuremaster, schemamaster, domainnamingmaster

Comment transférer des rôles FSMO à l’aide de l’outil de maintenance ntdsutil.exe

Pour transférer un rôle FSMO en utilisant ntdsutil.exe, suivez les étapes suivantes :

1. Ouvrez une invite de commandes avec élévation de privilèges.
2. Saisissez ntdsutil et appuyez sur Entrée. Une nouvelle fenêtre s’ouvre.
3. Dans la fenêtre, à l’invite de commandes ntdsutil, saisissez roles et appuyez sur Entrée.
4. À l’invite de commandes fsmo maintenance, saisissez connections et appuyez sur Entrée.
5. À l’invite de commandes server connections, saisissez connect to server <DC> (en remplaçant <DC> par le nom d’hôte du contrôleur de domaine vers lequel le rôle FSMO est transféré) et appuyez sur Entrée. Ces commandes permettent d’établir une connexion entre ntdsutil et le contrôleur de domaine spécifié.
6. Saisissez quit et appuyez sur Entrée.
7. À l’invite de commandes fsmo maintenance, saisissez la commande correspondante à chacun des rôles que vous souhaitez transférer :
   • transfer schema master
   • transfer naming master
   • transfer rid master
   • transfer infrastructure master
   • transfer pdc
8. Pour quitter l’invite de commandes fsmo maintenance, saisissez quit et appuyez sur Entrée.
9. Pour quitter l’invite de commandes ntdsutil, saisissez quit et appuyez sur Entrée.

Saisie des rôles FSMO

Le transfert des rôles FSMO nécessite que les contrôleurs de domaine source et cible soient tous les deux en ligne et qu’ils fonctionnent sans erreurs. Lorsqu’un contrôleur de domaine qui héberge un ou plusieurs rôles FSMO ne fonctionne plus ou qu’il n’est pas disponible pendant une durée considérable, ses rôles FSMO peuvent être saisis plutôt que transférés.

Dans la plupart des cas, la saisie des rôles FMSO est une opération qui doit être effectuée uniquement si le propriétaire du rôle FSMO d’origine ne peut pas être ramené dans l’environnement. Dans le cas contraire, la réintégration du propriétaire du rôle FSMO après la saisie de ses rôles peut provoquer des dégâts significatifs dans le domaine ou la forêt. C’est particulièrement vrai pour les rôles de contrôleur de schéma et de maître RID.

Pour saisir des rôles FSMO, vous pouvez utiliser la cmdlet Move-ADDirectoryServerOperationMasterRole en appliquant le paramètre ?Force. La cmdlet tentera de transférer le rôle FSMO. En cas d’échec, elle le saisira.

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.

Toutefois, votre stratégie de sécurité ne se limite pas uniquement aux seuls rôles FSMO : vous devez comprendre et contrôler ce qui se passe au sein de vos systèmes noyaux. Netwrix Auditor for Active Directory va bien au-delà de la simple protection des rôles FSMO ; il simplifie la gestion rigoureuse et le contrôle des modifications au cœur de votre domaine Active Directory.

En automatisant le suivi des modifications et la création de rapports, Netwrix Auditor vous donne les moyens de réduire les risques de sécurité. Notre solution vous permet d’améliorer votre posture de sécurité en identifiant de manière proactive les menaces internes, par exemple des autorisations accordées directement, et en y remédiant avant que des attaquants ne les exploitent pour obtenir un accès aux ressources de votre réseau. Vous pouvez également effectuer un suivi des modifications et de l’ensemble des changements au sein de l’Active Directory afin de détecter des menaces émergentes et y réagir rapidement, limitant ainsi leur impact sur les processus d’entreprise, la productivité des utilisateurs et la sécurité.