Comprendre les rôles FSMO dans Active Directory

Si votre organisation fonctionne avec Microsoft Active Directory, vous dépendez d'un ou plusieurs contrôleurs de domaine pour maintenir les opérations AD. En apparence, Active Directory semble fonctionner selon un modèle pair-à-pair dans lequel chaque contrôleur de domaine (DC) a l'autorité de créer, modifier et supprimer des objets AD. Cela est dû au fait que chaque contrôleur de domaine détient une copie modifiable de la partition de son domaine, la seule exception étant les DC en lecture seule. Une fois les modifications ou ajouts effectués, ils sont synchronisés avec les autres DC via une réplication multi-maîtres. Cependant, certaines opérations cruciales sont limitées à certains DC qui se voient attribuer des rôles spéciaux connus sous le nom de rôles d'opérations de maître unique flexible (FSMO) ou rôles de maître d'opération.

Ci-dessous, nous détaillons l'importance des rôles FSMO dans Active Directory et partageons quelques bonnes pratiques pour garantir une gestion et une protection efficaces.

Introduction aux rôles FSMO

FSMO signifie Flexible Single Master Operations, un terme issu du travail de Microsoft pour pallier les limitations du modèle de réplication multi-maître dans AD. Les rôles FSMO garantissent le fonctionnement et la cohérence de l'Active Directory à travers un domaine Windows en attribuant une tâche critique spécifique à des contrôleurs désignés et en fournissant un processus d'autorité unique pour le changement. En centralisant ces opérations au sein de contrôleurs de domaine spécifiques, les rôles FSMO contribuent à maintenir l'intégrité et la stabilité des environnements Active Directory.

Il existe cinq rôles FSMO uniques. Par défaut, lorsque vous créez un Active Directory domain, tous les rôles FSMO sont attribués au premier contrôleur de domaine de la forêt. Les administrateurs de domaine peuvent réaffecter les rôles FSMO à d'autres contrôleurs de domaine si nécessaire.

La nécessité des rôles FSMO

Avant de nous plonger dans les rôles FSMO réels, il est important de comprendre l'architecture multi-maître qui crée le besoin pour eux.

Modèle multi-maître vs. Modèle mono-maître

L'architecture réseau initiale de Microsoft était basée sur un Modèle à Maître Unique dans lequel un seul serveur détenait la copie modifiable de la base de données contenant tous les comptes d'objets utilisateurs et ordinateurs. Ce serveur était le seul responsable de l'ajout ou de la modification des comptes dans la base de données. Les autres serveurs du réseau maintenaient des copies en lecture seule de la base de données. Bien que ces serveurs pouvaient authentifier les utilisateurs, ils ne pouvaient pas modifier la base de données. Si le maître était hors ligne ou fonctionnait mal, aucun nouveau compte ne pouvait être créé et les comptes existants ne pouvaient pas être modifiés. Cela créait un point de défaillance unique.

Pour pallier les limitations du modèle à maître unique, Microsoft est passé à un modèle à multi-maîtres dans Active Directory (AD), où chaque contrôleur de domaine (DC) conserve une copie modifiable de la base de données des comptes. Cette conception assure la redondance et la résilience, les opérations pouvant continuer même si un DC devient indisponible. Cependant, cette approche multi-maîtres a introduit le potentiel de conflits, où différents DC pourraient tenter d'effectuer des modifications contradictoires simultanément. Pour prévenir de telles incohérences et maintenir l'intégrité et la performance d'AD, Microsoft a introduit les rôles d'opérations de maître unique flexible (FSMO).

Importance des rôles FSMO dans AD

En attribuant des rôles FSMO, Active Directory assure que des opérations essentielles—telles que les mises à jour du schéma, la dénomination de domaine et la synchronisation de l'heure—soient gérées de manière ordonnée et cohérente. Si le DC détenant un rôle FSMO spécifique tombe en panne, le rôle peut être transféré à un autre DC, assurant ainsi la continuité. La distribution des rôles FSMO est cruciale pour maintenir un réseau équilibré et efficace, et les organisations peuvent personnaliser cette distribution en fonction de leurs besoins spécifiques et des meilleures pratiques pour la performance et la redondance.

Les 5 rôles FSMO d'Active Directory expliqués

Active Directory a cinq rôles FSMO uniques :

• Maître de schéma (niveau forêt)
• Maître de nommage de domaine (niveau forêt)
• Maître de l'ID relatif (RID) (niveau de domaine)
• Émulateur du Contrôleur de Domaine Principal (PDC) (niveau de domaine)
• Maître d'infrastructure (niveau domaine)

Apprenons-en plus sur chaque rôle FSMO et sa fonction spécifique au sein de l'infrastructure Active Directory :

Maître de schéma

Quel est le rôle du maître de schéma FSMO ?

Le Schema Master est un rôle FSMO au niveau de l'entreprise, donc il n'y a qu'un seul Schema Master dans une forêt Active Directory. Le schéma définit les classes d'objets (types d'objets, comme les utilisateurs, les groupes et les ordinateurs) et leurs attributs qui peuvent exister dans la base de données AD database.

Quand et comment le maître de schéma est utilisé

Parfois, le schéma doit être modifié, par exemple, pour ajouter un nouveau type d'objet ou attribut requis. Pour éviter les mises à jour qui se chevauchent ou entrent en conflit, seul le DC avec le rôle de Schema Master peut traiter les modifications du schéma AD. Chaque fois qu'une mise à jour du schéma est effectuée, le Schema Master s'assure que les changements sont répliqués sur tous les autres DC dans la forêt.

Si une mise à jour du schéma est nécessaire, le Schema Master doit être disponible. Cependant, les modifications de schéma sont relativement rares dans la plupart des environnements. Les circonstances qui peuvent nécessiter un changement de schéma incluent la mise à niveau d'Active Directory, l'intégration de certains types de logiciels d'entreprise, l'élévation du niveau fonctionnel de la forêt et la mise à niveau du système d'exploitation d'un DC vers une version plus élevée que celle qui existe actuellement dans la forêt.

Maître de nommage de domaine

Rôles et responsabilités du Domain Naming Master

Le Domain Naming Master est un rôle au niveau de l'entreprise ; il n'y a qu'un seul Domain Naming Master dans une forêt Active Directory. C'est le seul DC capable d'ajouter de nouveaux domaines et partitions d'application à la forêt ou de retirer ceux existants de la forêt.

Scénarios courants impliquant le Domain Naming Master

Il se peut que vous deviez modifier votre forêt AD à mesure que votre entreprise évolue, ou que des domaines supplémentaires soient ajoutés à votre forêt en raison d'une fusion ou d'une acquisition. Étant donné que l'ajout et la suppression de domaines et de partitions sont des opérations peu fréquentes et rarement critiques en termes de temps, le rôle de Maître de Nomination de Domaine a peu de surcharge, et sa perte peut être considérée comme ayant peu ou pas d'impact opérationnel.

Maître RID

Quel est le rôle du maître RID ?

Le Relative Identifier Master (RID Master) est un rôle au niveau du domaine ; il y a un RID Master dans chaque domaine d'une forêt AD. Il est responsable de l'allocation des pools de RID aux DCs dans l'ordre de son domaine pour garantir que chaque principal de sécurité (tel qu'un utilisateur ou un groupe) dispose d'un identifiant de sécurité unique.

Un (SID) est une chaîne alphanumérique de longueur variable qui ressemble à ceci :

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

La première partie de la chaîne est le SID du domaine, qui est identique pour tous les SID dans un domaine. La dernière partie est le RID, qui est unique pour chaque SID dans le domaine. Dans l'exemple ci-dessus, 1001 est le RID attribué à un principal de sécurité particulier dans le domaine.

Fonctionnalité et utilisation du RID Master

Le RID Master attribue des pools de RID aux DCs. Chaque pool est composé d'une plage contiguë et unique de RIDs, que le DC peut utiliser pour générer un SID unique lorsqu'il crée un principal de sécurité. En gérant de manière centralisée la distribution des RIDs, le RID Master assure qu'aucun contrôleur de domaine n'attribue le même RID à différents principaux de sécurité, garantissant ainsi l'unicité de chaque SID au sein du domaine.

Une fois qu'un DC se voit attribuer un pool de RID par le RID Master, il n'a pas besoin de communiquer avec le RID Master à chaque fois qu'il crée un objet AD. Cependant, la perte du RID Master d'un domaine entraînera finalement l'incapacité de créer de nouveaux objets dans le domaine puisque les pools sur les DCs seront épuisés. Dans les environnements AD matures, cela prendrait un temps considérable car il y a relativement peu d'objets créés.

En général, le rôle de RID Master est attribué au contrôleur de domaine principal (PDC) dans un domaine car le PDC reçoit généralement le plus d'attention de la part des administrateurs et, par conséquent, dispose d'une haute disponibilité. Dans les domaines matures, la charge générée par le rôle de RID Master est négligeable. Bien que ce rôle ne soit pas aussi critique que certains des autres rôles, il est toujours important de garantir la connectivité au RID Master.

Émulateur PDC (PDCE)

Comprendre le rôle de l'émulateur PDC : explication et historique

Le Primary Domain Controller (PDC) est un terme des jours de Windows NT, quand un seul DC avait une copie modifiable de l'annuaire. Aujourd'hui, la plupart des DC dans un domaine sont modifiables, mais il y a toujours un DC désigné qui émule le rôle d'un PDC. Chaque domaine dans une forêt Active Directory contient un DC avec le rôle de PDCE.

Les fonctions de PDC Emulator dans AD

Le Primary Domain Controller Emulator est responsable des éléments suivants :

• Synchronisation de l'heure — Le PDCE est la source de temps autoritative pour le domaine ; tous les postes de travail et serveurs membres synchronisent leur heure avec l'émulateur PDC. Dans une forêt multi-domaines, le PDCE du domaine racine de la forêt est le gardien du temps pour tous les autres émulateurs PDC de la forêt. Pour maintenir une chronométrie précise dans toute la forêt, l'émulateur PDC du domaine racine doit être configuré pour se synchroniser avec une source de temps externe fiable. Le temps est une question très importante. Par exemple, l'authentification Kerberos échouera si la différence entre l'horloge d'un hôte demandeur et celle du contrôleur d'authentification dépasse le maximum spécifié (5 minutes par défaut) ; cela aide à contrer certaines activités malveillantes, telles que les attaques par rejeu.
• Changements de mot de passe et authentification —Lorsqu'un mot de passe d'utilisateur est modifié, le changement est initialement effectué sur le DC qui a authentifié l'utilisateur. Cette mise à jour de mot de passe engagée est immédiatement répliquée vers le PDCE du domaine. Si un compte tente de s'authentifier auprès d'un DC qui n'a pas encore reçu de changement de mot de passe récent par réplication planifiée, la demande est transmise au PDCE du domaine, qui traitera la demande d'authentification et instruira le DC demandeur d'accepter ou de rejeter celle-ci. Ce comportement garantit que les mots de passe peuvent être traités de manière fiable même si les changements récents ne se sont pas entièrement propagés par réplication planifiée.
• Statut de verrouillage de compte — De même, si un compte est verrouillé suite à plusieurs tentatives de connexion échouées, le verrouillage est traité immédiatement par l'émulateur PDC, et le statut de verrouillage est répliqué sur tous les DCs dans le domaine pour garantir qu'un compte verrouillé ne puisse pas se connecter à un autre DC. Lorsqu'un administrateur déverrouille un compte, ce changement est immédiatement répliqué à travers le domaine.
• Mises à jour de stratégie de groupe — Si des mises à jour sont effectuées sur un objet de stratégie de groupe (GPO), elles sont initialement validées sur le contrôleur de domaine avec le rôle d'émulateur PDC. Cela évite les conflits de versionnement qui pourraient survenir si un GPO était modifié sur deux contrôleurs de domaine en même temps environ.
• Compatibilité ascendante — Dans les organisations qui possèdent encore des appareils ou des logiciels anciens dépendant de Windows NT, l'émulateur PDCE peut faire office de PDC. Cela inclut la fonction de Master Browser, qui collecte et distribue des informations sur les applications et les appareils sur un réseau.
• Système de fichiers distribué (DFS) — Par défaut, les serveurs racine DFS demanderont périodiquement des informations mises à jour de l'espace de noms DFS auprès du PDCE. Ce comportement peut entraîner des goulots d'étranglement des ressources, mais l'activation du paramètre Dfsutil.exe RootScalability permettra aux serveurs racine DFS de demander des mises à jour auprès du DC le plus proche.

Le rôle d'Émulateur PDC doit être placé sur un DC hautement accessible, bien connecté et performant, car la perte du DC avec ce rôle peut avoir un impact immédiat et significatif sur les opérations.

Maître d'infrastructure

Rôle du maître FSMO d'infrastructure

Le rôle principal de l'Infrastructure Master est de gérer les références des objets inter-domaines dans une forêt multi-domaines. L'Infrastructure Master compare les objets de son domaine avec ceux des autres domaines dans la même forêt et les synchronise avec les serveurs de global catalog .

Quand et pourquoi le Infrastructure Master est nécessaire

Ces actions ne sont pas nécessaires dans certains cas. De toute évidence, dans des environnements avec un seul domaine AD, il n'y a pas de références inter-domaines à gérer. Et si tous les DCs d'un domaine sont des hôtes de global catalog (ce qui est courant aujourd'hui en raison de la meilleure bande passante réseau), ils auront tous des informations à jour sans dépendre du Maître de l'Infrastructure.

Le maître de l'infrastructure se voit attribuer les responsabilités suivantes :

• Références d'objets inter-domaines — Dans une forêt multi-domaines, les objets d'un domaine peuvent être référencés dans un autre domaine. Un exemple typique est lorsqu'un utilisateur d'un domaine est ajouté à un groupe de sécurité dans un autre domaine. Dans ce scénario, un espace réservé (appelé un « objet fantôme ») est créé dans le domaine du groupe pour représenter l'utilisateur de l'autre domaine. Les objets fantômes suivent et gèrent les références persistantes aux objets supprimés et les attributs à valeur de lien qui se réfèrent à des objets dans un autre domaine de la forêt.
• Mise à jour des références de groupe à utilisateur —Le Infrastructure Master est responsable de la mise à jour de l'identifiant de sécurité (SID) d'un objet et du nom distinctif (DN) dans une référence d'objet inter-domaines et de la traduction des GUIDs, SIDs et DNs entre les domaines dans une forêt.
• Nettoyage des objets obsolètes — Le maître de l'infrastructure vérifie régulièrement son domaine pour les objets qui ne sont plus valides (tels que les objets issus de confiances supprimées) et les supprime.

Si un DC avec le rôle de Infrastructure Master échoue, l'impact est principalement administratif. Bien que les noms de liens d'objets inter-domaines pourraient ne pas se résoudre correctement pendant son absence, les appartenances aux groupes inter-domaines fonctionneront toujours.

Rôles FSMO dans les contextes de forêt et de domaine

Rôles FSMO au niveau de la forêt

Comme vous pouvez le voir dans la liste ci-dessus, les deux derniers rôles FSMO fonctionnent à l'échelle de la forêt, ce qui signifie qu'un seul DC dans la forêt peut être le détenteur du rôle. En d'autres termes, chaque forêt Active Directory a un seul Schema Master et un seul Domain Naming Master.

Rôles FSMO au niveau du domaine

Les trois autres rôles FSMO fonctionnent dans la juridiction d'un seul domaine. Dans chaque domaine, il y a un Maître d'Infrastructure, un Maître RID et un Émulateur PDC. Chaque domaine hébergera ces trois rôles FSMO dans des environnements avec plusieurs domaines sur un ou plusieurs DC.

Gestion des rôles FSMO

Identification des détenteurs de rôles FSMO

Savoir quels contrôleurs de domaine (DC) dans votre environnement AD hébergent les 5 rôles FSMO est important. Il existe plusieurs méthodes pour identifier les DC qui possèdent les rôles FSMO. Une manière rapide est d'utiliser l'invite de commande avec la commande suivante :

      netdom query fsmo /domain:<DomainName>
      

Voici un exemple :

Vous pouvez également utiliser PowerShell en utilisant le script suivant :

      (Get-ADForest).Domains |

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

Select-Object Domain, HostName, OperationMasterRoles
      

Voici un exemple ci-dessous utilisant PowerShell :

Vous pouvez également découvrir quels DC sont attribués les rôles FSMO en utilisant les outils Windows Active Directory Tools. En utilisant Active Directory Users and Computers, cliquez-droit sur votre domaine et sélectionnez Maîtres d'opérations comme indiqué ci-dessous :

Ensuite, cliquez sur chaque onglet pour trouver les trois FSMO de domaine.

You can use Active Directory Domains and Trusts to find which DC holds the Domain Naming Master role by right-clicking on Active Directory Domains and Trust and then selecting Operations Master, as shown below.

Ce qui affichera alors la fenêtre pop-up suivante pour identifier le détenteur du rôle actuel.

Le processus d'identification du maître de schéma FSMO est un peu plus complexe. Vous pouvez trouver son identité en utilisant le composant logiciel enfichable Schéma Active Directory, cependant, ce dernier n'apparaît pas par défaut dans Windows Server. Pour y accéder, vous devez l'enregistrer en utilisant le fichier Schmmgmt.dll. Pour cela, cliquez sur Démarrer > Exécuter, et tapez regsvr32 schmmgmt.dll dans la boîte Ouvrir. Puis cliquez sur OK comme indiqué ci-dessous.

Une fois enregistré avec succès, vous devez faire ce qui suit :

1. Dans le menu Console, cliquez sur Add/Remove Snap-in, cliquez sur Ajouter, double-cliquez sur Active Directory Schema, cliquez sur Fermer, puis sur OK.
2. Cliquez avec le bouton droit sur Active Directory Schema dans le volet supérieur gauche, puis cliquez sur Operations Masters pour voir le serveur qui détient le rôle de maître de schéma.

Un exemple est montré dans la capture d'écran ci-dessous :

Cela vous donnera accès au composant logiciel enfichable à partir duquel vous pourrez cliquer avec le bouton droit sur Active Directory Schema et choisir Operations Master.

Transfert et saisie des rôles FSMO

Quand et comment transférer les rôles FSMO

Bien que Active Directory attribue automatiquement les rôles FSMO à vos contrôleurs de domaine, il peut arriver que vous souhaitiez transférer un rôle à un autre contrôleur de domaine. Par exemple, vous pourriez avoir besoin de mettre hors service un contrôleur de domaine qui détient actuellement un rôle assigné. Les administrateurs de domaine et d'entreprise ont la discrétion de déplacer ces rôles entre les contrôleurs de domaine selon les besoins.

Saisie des rôles FSMO

Pour les transferts de rôles FSMO, le détenteur actuel du rôle et le contrôleur de domaine cible doivent être actifs et connectés au réseau. Si le détenteur actuel du rôle FSMO est indisponible et ne peut être restauré, un administrateur de domaine ou d'entreprise devra s'emparer du rôle. Comme il s'agit d'une action plus abrupte, la prise de contrôle d'un rôle FSMO ne doit être effectuée que lorsque cela est nécessaire.

Meilleures pratiques et dépannage

Optimisation du placement des rôles FSMO pour une plus grande efficacité

Bien qu'il n'y ait pas de règles strictes et définitives concernant le placement des FSMO au sein d'Active Directory, les recommandations suivantes vous garantiront les meilleurs résultats :

• Placez l'émulateur PDC et le maître RID sur un contrôleur de domaine fiable avec une bonne connectivité, qui est facilement accessible aux autres contrôleurs de domaine, car leurs rôles sont essentiels pour les activités quotidiennes d'Active Directory.
• Si possible, le maître de l'infrastructure ne devrait pas être placé sur un serveur de catalogue global. Cela n'est bien sûr pas possible si tous les DCs sont des serveurs de catalogue global.
• Placez les deux rôles du côté de la forêt (Schema Master et Domain Naming Master) sur le même DC, car ils ne sont pas utilisés très souvent.

Problèmes courants et solutions

Il existe certaines instances clés qui peuvent indiquer qu'un FSMO n'est pas disponible. Par exemple, toute tentative de mise à jour du schéma AD se soldera par une erreur si le Schema Master est hors service. Vous ne pourrez également pas ajouter ou retirer des domaines dans la forêt si le Domain Naming Master n'est pas accessible. Dans ces circonstances, vous devez confirmer quel DC a ce rôle et vérifier qu'il est accessible.

L'incapacité d'accéder à un DC avec un rôle FSMO attribué peut résulter de plusieurs facteurs, y compris :

• Le serveur étant hors ligne ou éteint
• Problèmes de connectivité réseau
• Erreurs ou échecs de configuration DNS

La résolution de ces problèmes peut nécessiter l'utilisation d'outils de diagnostic réseau pour vérifier la connectivité dans tout le réseau, vérifier les paramètres DNS y compris les enregistrements SRV, et assurer la santé physique et logique du serveur détenant le rôle FSMO. Si le problème persiste, envisagez de transférer le rôle à un autre DC sain ou, en dernier recours, de saisir le rôle si le détenteur actuel est définitivement indisponible.

Surveillance et audit des rôles FSMO

Parce que ces rôles FSMO sont si critiques, vous devriez régulièrement surveiller les serveurs qui détiennent ces rôles. À un niveau très basique, vous pouvez vérifier les journaux d'événements sur vos contrôleurs de domaine. Des événements spécifiques peuvent indiquer quand les rôles FSMO ont été transférés ou saisis. Votre organisation peut également utiliser des logiciels de surveillance ou de gestion qui pourraient avoir des données historiques ou des alertes liées aux changements de rôles FSMO. Il existe aussi des outils tiers qui offrent beaucoup plus de fonctionnalités. Un exemple est Netwrix Auditor for Active Directory qui automatise la surveillance des rôles FSMO et peut vous alerter de tout changement suspect ou imprévu. Il est également considéré comme une meilleure pratique de documenter quand ces changements de rôles FMSO ont lieu afin que ce type d'historique puisse être consulté si nécessaire.

Comment Netwrix peut aider

Comme nous l'avons vu, les rôles FSMO sont importants pour la continuité des activités et la sécurité. Par conséquent, il est essentiel d'auditer tous les changements apportés à vos rôles FSMO. Netwrix Auditor for Active Directory automatise cette surveillance et peut vous alerter de tout changement suspect afin que vous puissiez agir avant qu'il ne mène à une interruption de service ou à une data breach.

Bien sûr, la protection des rôles FSMO n'est qu'une partie d'une stratégie de sécurité. Netwrix Auditor for Active Directory offre une visibilité complète et un contrôle sur les systèmes centraux dont vous avez besoin. Il surveille et analyse en continu les modifications et autres activités dans Active Directory pour détecter les menaces émergentes et vous donne le pouvoir de répondre rapidement et efficacement afin de minimiser l'impact sur les processus d'affaires, la productivité des utilisateurs et la sécurité.

Conclusion

Les rôles FSMO dans AD sont un exemple de tout ce qui se passe sous la surface. Bien que les rôles FSMO au niveau de la forêt ne soient pas critiques tous les jours, votre entreprise dépend néanmoins des rôles et services FSMO de votre domaine. En plus de la menace de pannes attendues qui surviennent périodiquement, ces rôles constituent des cibles idéales pour les acteurs de menaces malveillants qui cherchent à perturber les opérations commerciales. Cela signifie que vous avez besoin de visibilité sur les complexités de votre environnement AD.

Les équipes de support AD adoptent de plus en plus d'outils de surveillance automatisés pour relever ces défis. Ces solutions peuvent fournir :

• Visibilité améliorée sur le statut et la performance des détenteurs de rôles FSMO
• Alertes en temps réel concernant tout changement ou anomalie dans les attributions de rôles FSMO
• Identification proactive des problèmes potentiels avant qu'ils ne s'aggravent
• Des capacités d'audit étendues qui peuvent suivre les changements historiques.

Cette approche proactive peut aider les administrateurs AD à maintenir la santé et la stabilité d'une infrastructure AD et à renforcer la posture de sécurité globale de l'organisation.

FAQ

Qu'est-ce que FSMO ?

FSMO signifie Flexible Single Master Operations. Ces opérations sont des responsabilités spéciales attribuées à des contrôleurs de domaine spécifiques pour éviter les conflits et assurer le bon fonctionnement du réseau.

Quels sont FSMO et ses rôles ?

Active Directory repose sur un modèle multi-maître dans lequel FSMO attribue une autorité désignée à des contrôleurs de domaine désignés.

Quels sont les 5 rôles FSMO et comment vérifieriez-vous les détenteurs de rôles ?

Les 5 rôles FSMO sont les suivants :

• Schema Master: Responsable des mises à jour du schéma AD.
• Domain Naming Master: Contrôle l'ajout ou la suppression de domaines dans la forêt.
• Maître RID (Relative ID): Attribue des pools de RID aux DC pour créer des identifiants de sécurité uniques (SIDs).
• Émulateur PDC (Primary Domain Controller): Celui-ci gère les changements de mot de passe et la synchronisation de l'heure et sert de solution de secours pour certains types d'authentification.
• Infrastructure Master: Gère les références aux objets dans d'autres domaines

En utilisant les outils standard Active Directory et PowerShell, vous pouvez trouver quels contrôleurs de domaine sont les détenteurs de ces rôles FSMO.

Où se trouvent les rôles FSMO ?

Par défaut, le premier contrôleur de domaine d'un domaine racine de forêt Active Directory héberge le Maître de schéma et le Maître de nommage de domaine. Le premier contrôleur de domaine de chaque domaine héberge l'Émulateur PDC, le Maître RID et le Maître d'infrastructure. Les administrateurs Active Directory peuvent déplacer ces rôles vers d'autres DC s'ils le souhaitent.

Pourquoi saisit-on les rôles FSMO ?

Si un contrôleur de domaine se déconnecte soudainement, son rôle FSMO devient indisponible. Un transfert de rôle n'est pas possible s'il n'y a pas de connectivité avec le détenteur du rôle original. Dans ce cas, le rôle devra être saisi et attribué à un autre DC.

Quel est le rôle FSMO le plus important ?

Alors que tous les rôles FSMO sont importants, l'Emulateur PDC est le plus crucial car il gère l'heure pour le domaine, les changements de mot de passe et la configuration des group policy. Dans certains cas, les systèmes hérités peuvent en dépendre comme unique moyen de traitement des demandes d'authentification.

Comment trouver les rôles FSMO ?

Il existe plusieurs méthodes pour découvrir quels contrôleurs de domaine possèdent les rôles FSMO d'Active Directory. L'une consiste à utiliser la commande “netdom query fsmo” via l'invite de commande. Vous pouvez également utiliser les outils Active Directory et PowerShell pour déterminer quel serveur héberge chaque rôle.

Où doivent être placés les rôles FSMO ?

Si vous n'avez qu'un ou deux contrôleurs de domaine dans votre environnement AD, vous n'avez pas vraiment le choix. Tous les rôles FSMO doivent être attribués à un DC qui dispose d'une bonne connectivité avec tous les autres DC de la forêt. Si possible, le Maître de l'Infrastructure ne devrait pas être placé sur un serveur de catalogue global.

Quels rôles FSMO devraient être regroupés ?

Les deux rôles FSMO au niveau de la forêt du Schema Master et du Domain Naming Master devraient être placés sur le même DC, mais ce n'est qu'une recommandation.