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.

Quels sont les rôles FSMO dans Active Directory ?

Microsoft a réduit le risque de conflit en désignant certains contrôleurs de domaine comme seule autorité pour cinq opérations sensibles. Ce sont les rôles Flexible Single Master Operations (FSMO), et les comprendre est essentiel pour gérer un environnement Active Directory stable et bien gouverné.

Active Directory fonctionne selon un modèle multi-maître dans lequel chaque contrôleur de domaine conserve une copie modifiable de sa partition de domaine. Cette conception offre une résilience (les opérations continuent même lorsque certains DC sont hors ligne), mais elle introduit aussi la possibilité de modifications conflictuelles.

Ce guide explique chacun des cinq rôles FSMO, comment identifier les contrôleurs de domaine qui les détiennent, et fournit les commandes nécessaires pour transférer ou saisir les rôles lorsque les circonstances l’exigent.

Chacun des cinq rôles FSMO appartient à l’un des deux périmètres :

Par défaut, lorsque vous promouvez le premier contrôleur de domaine dans une forêt, les cinq rôles FSMO sont attribués à ce contrôleur. Les administrateurs peuvent les redistribuer à mesure que l’environnement se développe et que les besoins opérationnels évoluent.

FSMO signifie Flexible Single Master Operations et fait référence à cinq opérations Active Directory que seul un contrôleur de domaine désigné peut traiter à la fois. En limitant ces opérations à un seul DC autoritaire par périmètre, Active Directory empêche les collisions de données qui surviendraient si plusieurs contrôleurs tentaient de les exécuter simultanément.

Netwrix Auditor surveille les affectations de rôles FSMO dans Active Directory et alerte votre équipe lorsqu’un transfert ou une saisie de rôle se produit en dehors d’une fenêtre de maintenance planifiée. Obtenez une démo

Pourquoi la réplication multi-master nécessite des opérations single-master

Les rôles à l’échelle du forest ont exactement un titulaire dans l’ensemble du forest AD, quel que soit le nombre de domaines qu’il contient. Les rôles à l’échelle du domaine ont exactement un titulaire par domaine Active Directory, donc un forest avec trois domaines contient trois RID Masters, trois PDC Emulators et trois Infrastructure Masters.

Importance des rôles FSMO

Prévention des conflits

Les premiers services d’annuaire réseau reposaient sur un modèle à maître unique : un serveur détenait la copie modifiable de la base de données des comptes tandis que tous les autres conservaient des répliques en lecture seule. Ce modèle évitait les conflits mais créait une forte dépendance à un seul serveur : s’il était hors ligne, aucun nouveau compte ne pouvait être créé et aucun compte existant modifié.

Les rôles FSMO maintiennent Active Directory cohérent, sécurisé et récupérable. Leur importance ne devient claire que lorsqu’un problème survient : un contrôleur de domaine échoue, un transfert de rôle est nécessaire sous pression, ou un attaquant cible un détenteur de rôle.

Active Directory a remplacé ce modèle par une réplication multi-maître. Chaque contrôleur de domaine peut écrire sur sa copie locale de l’annuaire, et les modifications se propagent à tous les autres contrôleurs via une réplication programmée. La conception offre de la résilience, mais expose des opérations spécifiques où deux contrôleurs agissant simultanément corrompraient l’annuaire. Les rôles FSMO résolvent cela en imposant une autorité de maître unique précisément là où le modèle multi-maître ne peut pas fonctionner en toute sécurité.

Fiabilité de l'authentification

Posture de sécurité

Sans autorités maître unique désignées, deux contrôleurs de domaine pourraient simultanément traiter des opérations conflictuelles : l’un attribuant le RID 1050 à un nouveau compte utilisateur tandis que l’autre attribue le même RID à un compte différent, ou deux administrateurs étendant le schéma avec des définitions d’attributs incompatibles. Chacun de ces cas entraîne une corruption de l’annuaire sans solution claire. Les rôles FSMO garantissent qu’à tout moment, chaque opération sensible dispose d’une source autoritaire unique.

Reprise après sinistre

Quels sont les 5 rôles FSMO

La désignation FSMO du PDC Emulator explique pourquoi votre service d’assistance peut déverrouiller un compte et que cela prenne effet en quelques secondes dans tout le domaine. Sans cela, Kerberos authentication les décisions reposeraient sur la version du mot de passe que détient un DC donné à ce moment-là, créant des conditions de concurrence entre les changements récents de mot de passe et les tentatives de connexion. Le modèle de maître unique pour le traitement des mots de passe donne à chaque DC une voie d’escalade connue en cas d’échec d’authentification, et cette voie ne fonctionne que parce qu’un DC détient le rôle de PDC Emulator.

Trois des cinq rôles FSMO se trouvent directement sur la trajectoire des scénarios d'attaque à haute valeur. Le Schema Master contrôle si un attaquant peut étendre le schéma de l'annuaire pour introduire des mécanismes de persistance. Le RID Master contrôle l'attribution des SID, et la manipulation des RID est un vecteur connu pour privilege escalation et les attaques sur l'historique des SID. Le PDC Emulator traite l'authentification et les verrouillages de compte, en faisant une cible de choix pour quiconque tente de maintenir l'accès au domaine ou de supprimer les alertes de verrouillage.

Active Directory définit cinq rôles FSMO. Le Schema Master et le Domain Naming Master fonctionnent au niveau de la forêt. Le RID Master, le PDC Emulator et l’Infrastructure Master fonctionnent au niveau du domaine.

1. Maître de Schéma

Lorsqu'un contrôleur de domaine détenant un rôle FSMO tombe en panne, la voie de récupération dépend de la connaissance par votre équipe des rôles qu'il détenait et de la nature temporaire ou permanente de la panne. Les organisations qui ne suivent pas les attributions de rôles découvrent la faille sous pression : impossibilité de créer de nouveaux comptes utilisateurs, dérive de la synchronisation horaire ou arrêt de la propagation des mises à jour de Group Policy. Documenter les détenteurs de rôles et tester les procédures de transfert sont la base opérationnelle pour la résilience d'AD.

Chaque forêt a un Schema Master. Le schéma de la base de données Active Directory database définit chaque classe d’objet (utilisateurs, groupes, ordinateurs, imprimantes, etc.) et chaque attribut que ces objets peuvent contenir. Seul le Schema Master peut écrire des modifications du schéma.

2. Maître de nommage de domaine

Chaque forêt possède un Domain Naming Master. C'est le seul contrôleur de domaine autorisé à ajouter ou supprimer des domaines et des partitions d'applications de la forêt.

Les mises à jour du schéma sont rares. Elles se produisent lorsque vous augmentez le niveau fonctionnel de la forêt, mettez à niveau Active Directory vers une version plus récente, intégrez un logiciel d'entreprise qui étend le schéma (Exchange Server est un exemple courant) ou introduisez une nouvelle version du système d'exploitation Windows Server dans la forêt. Le Schema Master doit être en ligne et accessible pour que l'une de ces opérations réussisse.

Une fois validée, une modification du schéma se réplique sur chaque contrôleur de domaine de la forêt. Si le Schema Master est hors ligne lors de la tentative de mise à jour du schéma, l’opération échoue jusqu’à ce que le DC soit à nouveau accessible.

3. RID Master

Un SID suit cette structure :

Vous interagissez avec le Domain Naming Master lorsque la structure de l’annuaire de votre organisation change : ajout d’un domaine enfant, suppression d’un domaine obsolète ou absorption de domaines d’une entreprise acquise. Comme ces opérations sont peu fréquentes et rarement critiques en termes de temps, le Domain Naming Master a des exigences de disponibilité inférieures à celles des rôles au niveau du domaine. Une brève interruption du Domain Naming Master n’a aucun impact sur les opérations quotidiennes.

Le RID Master maintient cette unicité en attribuant des pools de RID aux contrôleurs de domaine. Lorsqu’un DC doit créer un nouveau principal de sécurité, il puise un RID dans son pool attribué plutôt que de contacter le RID Master pour chaque objet. Une fois qu’un pool est presque épuisé, le DC en demande un nouveau au RID Master.

Si le RID Master est hors ligne, les contrôleurs de domaine continuent de créer des objets en utilisant leurs pools RID existants. Dans les environnements matures avec de grands pools, cela peut durer longtemps. Finalement, une fois que tous les pools DC sont épuisés, la création d’objets échoue.

4. Émulateur PDC

Chaque domaine possède un RID Master. Chaque principal de sécurité dans Active Directory (utilisateurs, ordinateurs et groupes) nécessite un identificateur de sécurité (SID) unique. Un SID se compose d'un préfixe global au domaine suivi d'un identificateur relatif (RID). La partie RID est ce qui rend chaque SID unique dans le domaine.

Chaque domaine possède un émulateur PDC. Il assume plus de responsabilités que tout autre rôle FSMO et a l'impact le plus direct sur les opérations quotidiennes du domaine. L'émulateur PDC gère ce qui suit :

Le SID de domaine est le même pour tous les objets du domaine. Le segment final (1001 dans cet exemple) est le RID attribué à un principal de sécurité spécifique.

• Synchronisation de l'heure : L'émulateur PDC est la source de temps faisant autorité pour son domaine. Toutes les stations de travail et serveurs membres synchronisent leurs horloges avec lui. Dans une forêt multi-domaines, l'émulateur PDC du domaine racine de la forêt agit comme gardien du temps pour tous les autres émulateurs PDC de la forêt. L'émulateur PDC du domaine racine doit se synchroniser avec une source de temps externe fiable. L'authentification Kerberos échoue lorsque la différence d'heure entre un client et son DC authentifiant dépasse cinq minutes ; une heure précise n'est pas optionnelle.
• Traitement du verrouillage de compte : Lorsqu'un account lockout se produit, l'émulateur PDC le traite immédiatement et réplique le statut de verrouillage à tous les DC du domaine. Lorsqu'un administrateur déverrouille un compte, l'émulateur PDC réplique immédiatement la modification.
• Modifications de mot de passe et authentification : Lorsqu’un utilisateur change un mot de passe, la modification est immédiatement répliquée vers le PDC Emulator. Si un utilisateur tente de s’authentifier auprès d’un DC qui n’a pas encore reçu le mot de passe mis à jour via la réplication normale, ce DC transmet la demande d’authentification au PDC Emulator. Cela garantit que le domaine accepte des identifiants valides même lorsque les modifications récentes de mot de passe ne se sont pas encore propagées via la réplication programmée.

Placez l'émulateur PDC sur un DC haute performance avec une bonne connectivité réseau vers tous les autres contrôleurs du domaine. Sa défaillance a un impact immédiat et visible sur les opérations.

• Synchronisation de l’espace de noms DFS : Par défaut, les serveurs racines DFS demandent les informations mises à jour de l’espace de noms au PDC Emulator. Dans les grands environnements, cela peut créer des goulets d’étranglement des ressources. L’activation du paramètre RootScalability dans Dfsutil.exe permet aux serveurs racines DFS de demander des mises à jour au DC le plus proche.

5. Maître d'Infrastructure

• Mises à jour de Group Policy : Les modifications apportées à un Group Policy Object sont initialement enregistrées sur le DC détenant le rôle de PDC Emulator. Cela évite les conflits de version qui surviendraient si deux administrateurs modifiaient le même GPO sur différents DC en même temps.

Chaque domaine possède un Infrastructure Master. Sa responsabilité principale est de maintenir des références d’objets précises entre domaines dans une forêt multi-domaines.

Si l’Infrastructure Master est hors ligne, les noms d’objets inter-domaines peuvent ne pas se résoudre correctement. Les appartenances aux groupes inter-domaines continuent de fonctionner, donc l’impact opérationnel est principalement administratif.

Comment trouver les détenteurs des rôles FSMO

Deux conditions rendent l'Infrastructure Master inutile : les forêts à domaine unique (aucune référence inter-domaines) et les environnements où chaque DC est également un serveur de catalogue global (courant dans les environnements modernes avec une bande passante réseau suffisante). Dans les deux cas, tous les DC détiennent déjà des informations inter-domaines à jour sans dépendre de l'Infrastructure Master.

Lorsqu’un utilisateur d’un domaine est ajouté à un groupe de sécurité dans un autre domaine, Active Directory crée un objet fictif (appelé objet fantôme) dans le domaine du groupe pour représenter l’utilisateur inter-domaines. L’Infrastructure Master maintient ces objets fantômes à jour en les synchronisant avec le catalogue global. Il supprime également les objets obsolètes en supprimant les références aux objets issus de trusts ou domaines.

Utilisation de netdom query fsmo

Utilisation de PowerShell

Remplacez <DomainName>Expand par le nom de domaine complet du domaine cible. La sortie liste le nom d'hôte du DC détenant chaque rôle.

La commande netdomExpand s'exécute sur toute machine Windows jointe au domaine avec RSAT installé, ou directement sur un contrôleur de domaine. Elle renvoie les cinq détenteurs de rôles en une seule requête :

Utilisation des outils administratifs d’Active Directory

PowerShell offre un contrôle plus précis et fonctionne bien dans les environnements avec plusieurs domaines. Le script suivant interroge tous les domaines de la forêt et renvoie chaque DC avec une attribution de rôle FSMO :

Savoir quels contrôleurs de domaine détiennent les cinq rôles FSMO est une condition préalable à la fois pour la maintenance planifiée et la réponse aux incidents. Trois méthodes sont disponibles en utilisant les outils intégrés de Active Directory management tools.

Pour trouver le RID Master, PDC Emulator et Infrastructure Master :

1. Ouvrez Utilisateurs et ordinateurs Active Directory.

Pour une requête plus simple par domaine, utilisez Get-ADDomainExpand et Get-ADForestExpand directement :

Les outils GUI dans Active Directory Users and Computers affichent les trois rôles FSMO au niveau du domaine.

1. Cliquez avec le bouton droit sur le nom de domaine dans le volet de gauche et sélectionnez Operations Masters.
2. Ouvrez Active Directory Domains and Trusts.

Pour trouver le Domain Naming Master :

1. La boîte de dialogue affiche le Domain Naming Master actuel.
2. Examinez les onglets RID, PDC et Infrastructure, chacun affichant le titulaire actuel du rôle.
3. Cliquez avec le bouton droit sur Active Directory Domains and Trusts dans le volet de gauche et sélectionnez Operations Master.

Pour trouver le Schema Master : Le composant logiciel enfichable Active Directory Schema ne se charge pas par défaut. Enregistrez-le d'abord :

Comment transférer les rôles FSMO

1. Ouvrez la boîte de dialogue Exécuter (Win + R) et saisissez regsvr32 schmmgmt.dll. ExpandCliquez sur OK.

3. Cliquez avec le bouton droit sur Active Directory Schema dans le volet de gauche et sélectionnez Operations Master pour voir le Schema Master actuel.

2. Ouvrez MMC (mmc.exeExpand), allez dans Fichier > Ajouter/Supprimer un composant logiciel enfichable, et ajoutez Active Directory Schema.

Un transfert déplace un rôle FSMO de son détenteur actuel vers un autre DC pendant que les deux contrôleurs sont en ligne et communiquent. Utilisez un transfert pour des opérations planifiées : mise hors service d’un DC, redistribution des rôles pour la charge ou la redondance, ou remplacement de matériel vieillissant.

Transfert via PowerShell

Transférer un seul rôle :

Transférez les cinq rôles en une seule fois :

Les deux DC doivent être en ligne, accessibles et répliquer avec succès avant de commencer un transfert. Vérifiez l'état de la réplication avec repadmin /replsummaryExpand avant de continuer.

PowerShell est la méthode la plus efficace pour transférer des rôles, en particulier lors du déplacement de plusieurs rôles à la fois. La commande Move-ADDirectoryServerOperationMasterRoleExpand gère les cinq rôles.

Transfert via l'interface graphique :

Les cinq valeurs des noms de rôle sont SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster et InfrastructureMasterExpand.

Comment saisir les rôles FSMO

Remplacez TargetDCName Expandpar le nom NetBIOS ou FQDN du DC de destination. PowerShell demande une confirmation avant de transférer chaque rôle. Ajoutez -Confirm:$falseExpand pour supprimer les invites dans les scénarios scriptés.

Après tout transfert, exécutez netdom query fsmoExpand pour confirmer les nouvelles attributions de rôle.

Saisir des rôles avec ntdsutil :

Avant de saisir, essayez de restaurer ou récupérer le DC original. Si la récupération n’est pas possible, procédez à la saisie et assurez-vous de ne jamais rattacher le DC original au domaine sans l’avoir d’abord rétrogradé.

Pour le RID Master, PDC Emulator et Infrastructure Master : ouvrez ADUC, allez dans Operations Masters, sélectionnez l’onglet correspondant, puis cliquez sur Change. Pour le Domain Naming Master : utilisez Active Directory Domains and Trusts > Operations Master > Change. Pour le Schema Master : utilisez le composant logiciel enfichable Active Directory Schema > Operations Master > Change.

Après la connexion, saisissez chaque rôle individuellement :

Une seizure attribue de force un rôle FSMO à un nouveau DC sans coordination avec le détenteur original. Utilisez une seizure uniquement lorsque le détenteur actuel du rôle est définitivement hors ligne et irrécupérable. Ne pas saisir un rôle si le détenteur original peut revenir sur le réseau ; remettre en ligne un ancien détenteur de rôle après une seizure provoque une condition de split-brain nécessitant une correction manuelle.

Ouvrez une invite de commandes élevée sur le DC qui recevra les rôles et exécutez ntdsutilExpand. Ensuite, suivez ces étapes :

Tapez quit Expanddeux fois pour quitter ntdsutil après avoir terminé toutes les saisies.

Bonnes pratiques pour le placement des rôles FSMO

Confirmez les nouvelles affectations avec netdom query fsmoExpand avant de remettre en ligne les services dépendant de ces rôles.

Le placement des rôles affecte directement la stabilité et le temps de récupération d’AD. Consultez le guide des meilleures pratiques de sécurité d’Active Directory pour des recommandations plus larges de durcissement en plus de ces directives spécifiques aux rôles :

• Répartissez les rôles sur plusieurs sites physiques lorsque cela est possible : Dans les environnements multisites, placer les rôles sur les DC de votre site principal réduit la dépendance au WAN pour les opérations dépendantes des rôles. Associez cela à un plan de transfert documenté afin que les rôles puissent être déplacés rapidement si le site principal est hors ligne.
• Schema Master et Domain Naming Master ensemble, sur un DC moins utilisé : Ces rôles au niveau de la forêt sont rarement sollicités. Les regrouper sur le même DC simplifie l'administration sans créer de goulet d'étranglement des performances.

Pour des conseils sur la configuration des contrôleurs de domaine afin de soutenir ces décisions de placement, consultez le guide de déploiement des contrôleurs de domaine de Netwrix.

Comment Netwrix Auditor vous aide à surveiller et auditer les modifications des rôles FSMO

• Émulateur PDC et RID Master sur le DC le plus fiable du domaine : Les deux rôles exigent une haute disponibilité. La défaillance de l'émulateur PDC a un impact immédiat sur les utilisateurs ; la défaillance du RID Master s'accumule avec le temps à mesure que les pools se vident. Placez-les sur le DC le plus fiable et le mieux connecté du domaine.
• Infrastructure Master hors d’un serveur de catalogue global : Dans les environnements où tous les DC ne sont pas aussi des serveurs de catalogue global, l’Infrastructure Master doit fonctionner sur un DC qui ne détient pas une copie du catalogue global. Un Infrastructure Master qui détient également un catalogue global ne trouve jamais d’objets fantômes à mettre à jour, il ne peut donc pas maintenir les références inter-domaines à jour. Si tous les DC de votre domaine sont des serveurs de catalogue global (courant dans les environnements modernes), cette restriction ne s’applique pas.

Alertes en temps réel sur les changements de rôles FSMO

Netwrix Auditor pour Active Directory comble l’écart entre ce que les journaux natifs capturent et ce dont votre équipe de sécurité a besoin pour agir.

Active Directory enregistre les transferts FSMO dans le journal des événements du service d'annuaire sous l'ID d'événement 1458, consigné sur le contrôleur de domaine qui a reçu le rôle et nommant le détenteur précédent. L'événement confirme qu'un transfert a eu lieu, mais ne fournit pas le contexte complet du compte ni les détails de la session nécessaires à une enquête.

Pour avoir une vue complète de ce qu'il faut surveiller dans votre annuaire, les Active Directory auditing guidelines couvrent l'ensemble des événements à suivre.

Un transfert ou une prise non autorisée du rôle FSMO est un vecteur d’attaque confirmé dans AD avec des conséquences au-delà d’une simple interruption opérationnelle. Un attaquant qui obtient des privilèges suffisants sur un contrôleur de domaine peut s’emparer du rôle de PDC Emulator pour intercepter les demandes d’authentification, manipuler la synchronisation horaire ou contrôler la distribution de Group Policy dans tout le domaine. Ces modifications peuvent ne pas apparaître dans les journaux d’événements natifs de Windows avec suffisamment de contexte pour identifier l’acteur et l’intention.

Traçabilité complète avant et après audit

Netwrix Auditor alerte dès qu’un rôle FSMO est transféré ou saisi. Les alertes se déclenchent que le changement ait été effectué via PowerShell, l’interface graphique ou ntdsutil, et incluent le compte ayant initié le changement, le poste de travail source et l’horodatage. Votre équipe peut vérifier immédiatement les transferts planifiés et escalader les changements non reconnus avant que des dommages supplémentaires ne surviennent.

Rapports conformes aux exigences

Distinguer les transferts planifiés des saisies non autorisées

Chaque changement de rôle FSMO est enregistré avec le titulaire précédent, le nouveau titulaire, le compte ayant effectué l’action et l’heure exacte du changement. Les journaux d’événements natifs de Windows omettent ce contexte. Lorsqu’un incident nécessite une reconstitution (pour une enquête interne ou un audit externe), l’enregistrement complet est disponible sans dépendre de l’agrégation des journaux de plusieurs contrôleurs de domaine.

Parce que Netwrix Auditor capture le contexte complet du compte et de la session, votre équipe peut recouper les changements de rôle avec vos enregistrements de gestion des changements. Un transfert effectué par un compte administrateur nommé pendant une fenêtre de maintenance programmée est différent d'une saisie effectuée par un compte sans activité administrative préalable. La piste d'audit rend cette distinction claire et défendable.

Demandez une démo pour voir comment Netwrix peut vous aider à auditer les changements de rôles FSMO, suivre chaque modification d’Active Directory et produire les preuves prêtes pour l’enquête dont votre équipe de sécurité a besoin.

Les affectations de rôles FSMO font partie de l’empreinte d’accès privilégié que SOX, HIPAA, et les audits ISO 27001 examinent. Netwrix Auditor génère des rapports préconçus sur les modifications des privilèges Active Directory qui répondent aux demandes des auditeurs sans extraction manuelle des journaux. L’historique des modifications de rôles est conservé et consultable, de sorte que les preuves de conformité sont disponibles à la demande plutôt que rassemblées sous pression.