Active Directory (AD) est un service d’annuaire qui fournit des services d’authentification et d’autorisation centralisés. Les organisations hébergent AD sur des contrôleurs de domaine (DC) qui répliquent des informations entre eux dans une configuration multi-maître. Les rôles d’opération du maître unique (FSMO) garantissent des données cohérentes et fiables sur toutes les sources de données.
Les rôles FSMO aident à assurer le bon fonctionnement de la réplication AD et garantissent que de nombreux autres services critiques fonctionnent comme prévu. Dans cet article, vous apprendrez ce que sont les rôles FSMO, comment ils impactent AD et comment vous pouvez les manipuler en toute sécurité dans une forêt AD.
À la fin de cet article, vous comprendrez mieux les rôles FSMO et comment les gérer pour un environnement AD sain.
Quels sont les rôles FSMO ?
Les rôles FSMO sont des services hébergés de manière indépendante sur un DC dans une forêt AD. Chaque rôle a un but spécifique, tel que la synchronisation de l’heure entre les appareils, la gestion des identificateurs de sécurité (SIDs), et ainsi de suite.
Les rôles FSMO sont étendus au niveau de la forêt ou du domaine et sont uniques à cette portée, comme indiqué ci-dessous. Par exemple, une forêt avec deux domaines aura un DC dans chaque domaine (deux au total) hébergeant le rôle de maître RID, tandis qu’un seul DC hébergera le rôle de maître de schéma.
| FSMO Role | Scope |
| Schema Master | Forest |
| Domain Naming Master | Forest |
| Primary Domain Controller Emulator | Domain |
| RID Master | Domain |
| Infrastructure Master | Domain |
A DC can hold multiple roles at one time.
Maître de schéma
A critical component of AD is the database. The database, like all other databases, has a schema that dictates its structure with various partitions or naming contexts. The AD schema is a database partition that contains metadata about AD objects. For example, it contains classes like person, group, or msPKI-Key-RecoveryAgent and attributes like phone number, badPwdCount, or dNS-HostName.
Le schéma AD est la partition la plus « délicate » dans la base de données Active Directory.
AD a besoin d’un service pour gérer le schéma ainsi le rôle de Maître de schéma. Le rôle de Maître de schéma a pour devoir de contrôler les modifications du schéma AD. Si vous avez déjà étendu le schéma AD pour installer des produits comme Exchange ou élever un niveau fonctionnel de la forêt, vous avez travaillé avec le rôle de Maître de schéma.
Vous devriez effectuer toutes les modifications du schéma AD via le rôle de Maître de schéma uniquement sous des conditions strictes sur un seul DC. Vous ne voulez pas apporter des modifications sur deux DC et attendre la réplication pour voir quelle modification « gagne » via la réplication.
Maître du nom de domaine
Une base de données AD contient plusieurs partitions à la fois au niveau de la forêt et du domaine. AD apporte occasionnellement des modifications à ces partitions et a besoin d’un service pour le faire, ainsi le rôle FSMO de Maître du nom de domaine.
Lorsque vous apportez des modifications à l’espace de domaine de la forêt (ajouter des partitions à la forêt), le Maître du nom de domaine écrit ces modifications dans Configuration\\Partitions. Cette activité se produit lorsqu’un contrôleur de domaine est promu ou rétrogradé, par exemple.
Émulateur de contrôleur de domaine principal (PDCe)
De manière argumentée, le rôle FSMO le plus essentiel dans AD est celui du PDCe. Le rôle du PDCe est responsable de tâches telles que la synchronisation des modifications de mot de passe, les blocages de compte (et les déblocages), la synchronisation de l’heure, et bien d’autres.
Dans les premiers jours de l’Active Directory (Windows NT), le contrôleur de domaine principal (PDC) était le seul contrôleur de domaine en écriture dans un domaine AD. Tous les autres contrôleurs de domaine étaient des contrôleurs de domaine de sauvegarde (BDC) utilisés uniquement pour les demandes d’authentification
À partir de Windows 2000, tous les contrôleurs de domaine sont devenus en écriture, à l’exception des contrôleurs de domaine en lecture seule (RODC), introduits dans Windows Server 2008. Parce que l’AD avait toujours besoin de la fonctionnalité du PDC mais n’avait plus techniquement de PDC, Microsoft a introduit le rôle d’émulateur de PDC (PDCe).
Redirection des applications héritées
Une des fonctionnalités les plus basiques du rôle de PDCe est d’être disponible pour les applications héritées, leur indiquant que le DC sur lequel il est hébergé est celui où l’AD peut écrire des modifications. Par exemple, si vous avez encore la malchance de travailler avec un service Windows NT qui ne sait pas où écrire les modifications dans la base de données AD, il contactera le PDCe pour obtenir de l’aide.
Synchronisation du temps
Il est important que tous les appareils membres d’un domaine maintiennent une heure cohérente. L’authentification Kerberos (le mode d’authentification par défaut) nécessite un écart maximal de cinq minutes entre un client et un DC, ou entre les partenaires de réplication DC.
Le rôle de PDCe est la source de temps centrale pour tous les autres ordinateurs d’une forêt AD.
- Tous les ordinateurs clients synchronisent l’heure à partir du DC sur lequel ils se connectent.
- Tous les DC synchronisent l’heure à partir du PDCe de leur domaine.
- Dans les forêts AD multi-domaines, les DC hébergeant le rôle PDCe synchronisent leur temps à partir du PDCe dans le domaine parent.
- Le rôle PDCe dans le domaine racine utilise ensuite une source de temps externe fiable pour la synchronisation.
Gestion des modifications de mot de passe
Lorsqu’une modification est apportée à AD, cette modification n’est pas répliquée immédiatement sur tous les DC, mais suit plutôt le calendrier de réplication AD. Cependant, les modifications de mot de passe sont répliquées un peu différemment. Les changements de mot de passe se répliquent toujours d’abord du DC d’origine vers le DC tenant le rôle PDCe, puis vers les autres DC dans la topologie.
Par exemple, si un DC n’a pas actuellement le dernier mot de passe et qu’un utilisateur tente de s’authentifier avec l’ancien mot de passe, le DC d’authentification contacte d’abord le DC tenant le rôle PDCe pour vérifier s’il y a un mot de passe mis à jour avant de refuser l’authentification.
Vous remarquerez des problèmes avec le PDCe immédiatement lorsque vous découvrirez que les utilisateurs ayant changé de mot de passe rencontrent des problèmes pour se connecter à d’autres DC qui n’ont pas encore répliqué le nouveau mot de passe.
Traitement des verrouillages de compte
Le rôle PDCe traite également les verrouillages de compte. Contrairement aux changements de mot de passe, les verrouillages de compte ne suivent pas les intervalles de réplication réguliers. Les verrouillages de compte sont immédiatement répliqués aux autres DC via un mécanisme appelé réplication d’objet unique. Il s’agit d’une mesure de sécurité visant à garantir qu’un compte verrouillé ne peut pas se connecter à un autre DC qui n’a pas encore été répliqué.
Cible par défaut pour la Console de gestion des stratégies de groupe (GPMC)
La gestion des stratégies de groupe est effectuée avec l’outil Console de gestion des stratégies de groupe (GPMC). Pour apporter des modifications à AD, le GPMC doit se connecter à un DC. Par défaut, le GPMC se connectera toujours au DC qui détient le rôle PDCe même s’il est situé dans un site AD différent. Si le PDCe n’est pas accessible, vous recevrez un avertissement indiquant que le rôle PDCe n’est pas accessible et le GPMC vous demandera de choisir un autre DC.
Connexe: Qu’est-ce que la stratégie de groupe et comment fonctionne-t-elle (en détail)
Fourniture d’informations sur l’espace de noms du système de fichiers distribué (DFS)
Pour compléter la fonctionnalité du rôle FSMO PDCe, le rôle PDCe fournit des informations sur l’espace de noms DFS. Périodiquement, les serveurs racine DFS demanderont des informations sur l’espace de noms DFS mises à jour au PDCe qui détient des informations DFS autoritaires.
Alors que normalement ce n’est pas une charge excessive pour le rôle PDCe FSMO, vous modifiez le comportement par défaut de recherche de l’espace de noms DFS dans des environnements avec un grand nombre de serveurs DFS.
Maître RID
Chaque objet dans un domaine AD doit avoir un identifiant unique pour le différencier de tous les autres objets similaires. Il est essentiel que l’AD attribue toujours un identifiant unique à chaque nouvel objet appelé un identificateur de sécurité ou SID.
Chaque SID est composé de plusieurs composants : S (pour SID), le numéro de révision, I – l’Autorité de l’Identifiant -, l’ID de domaine et l’ID relatif. L’ID de domaine est unique à chaque domaine dans une forêt. L’ID relatif est unique à chaque objet dans un domaine. Un SID ressemble à ce qui suit avec un DomainId représentant l’ID de domaine et RelativeId représentant l’ID relatif.
Le rôle de maître de l’ID relatif (RID) garantit que le SID attribué à chaque objet AD est unique.
Certains RID sont réservés pour des comptes spéciaux et des groupes bien connus.
Le premier contrôleur de domaine (DC) dans le domaine devient automatiquement le maître RID pour maintenir le contrôle de l’émission des RID.
Le DC détenteur du rôle de maître RID intervient principalement dans trois événements différents:
Promotion/Déclassement de DC
Chaque fois qu’un nouveau DC est promu, le maître RID lui attribue un bloc de 500 RID. Ces RID sont ensuite attribués (dans l’ordre incrémental) lorsqu’un nouveau compte nécessitant un SID est créé sur ce DC.
Par exemple, si le dernier bloc de RID attribué allait de 5501 à …6000, le prochain DC ayant besoin d’un bloc (soit un DC nouvellement promu, soit un DC ayant épuisé son bloc actuel) recevra …6001 à …6500, et ainsi de suite.
Lorsqu’un DC est supprimé de la base de données Active Directory (AD), le maître RID le détecte et veille à ne pas attribuer l’un des RID que ce DC avait, par mesure de sécurité, afin d’éviter les SID en double.
Épuisement des RID
Lorsqu’un DC atteint une capacité RID de 50 %, il se rend auprès du maître RID et demande un nouveau bloc de RID. Les DC demandent de nouveaux RID à 50 % au cas où le maître RID serait hors ligne, ce qui leur donne amplement de temps tampon pour garantir que leur allocation RID n’est pas épuisée.
Saisie du rôle de maître RID
Les administrateurs peuvent déplacer des rôles d’un DC à un autre via la saisie ou le transfert de rôle FSMO. Lorsqu’un administrateur déplace le rôle de maître RID d’un DC à un autre, son prochain numéro RID disponible est incrémenté de 10000.
Connexe: Comment transférer les rôles FSMO (GUI et PowerShell)
Incrémenter le RID suivant disponible de 10000 est un mécanisme de sécurité mis en place pour éviter les SID en double. Si un administrateur prend le rôle de Maître RID, par exemple, et que l’ancien Maître RID revient en ligne, il peut commencer à émettre des SID en double avec le nouveau Maître RID.
Maître d’Infrastructure
Chaque objet AD a un SID attribué par le rôle FSMO du Maître RID. Lorsque vous consultez des utilisateurs, des groupes et d’autres informations AD, nous, les humains, voulons voir un nom et non un SID; c’est là que le rôle de Maître d’Infrastructure intervient.
Par défaut, chaque DC est configuré en tant que catalogue global (GC). Un GC héberge des informations de tous les domaines d’une forêt. Une façon de réduire le trafic de réplication entre les sites était de configurer certains DC pour ne pas être des GC.
Si vous étiez authentifié sur un DC qui n’était pas un GC, le Maître d’Infrastructure était responsable de la traduction des SID d’autres domaines en noms conviviaux pour les humains.
Par exemple, à partir d’un ordinateur joint à un domaine, vérifiez l’onglet Sécurité ou Partage d’un dossier dans l’Explorateur Windows avec des autorisations configurées pour des comptes dans un autre domaine. Vous verrez les noms d’utilisateurs, d’ordinateurs et de groupes; pas leurs SID. Si votre ordinateur ne peut pas trouver le rôle de Maître d’Infrastructure dans le domaine, vous verrez uniquement les SID des comptes dans d’autres domaines.
Si vous activez la Corbeille Active Directory, tous les DC se comportent techniquement comme s’ils détenaient le rôle de Maître d’Infrastructure. La Corbeille AD rend le rôle de Maître d’Infrastructure, selon les mots de Microsoft, non important.
Connexe : Comment sauvegarder votre peau avec la Corbeille Active Directory
Conclusion
Les rôles FSMO d’AD sont un composant essentiel pour garantir le bon fonctionnement d’AD. Bien que la plupart du temps, vous n’ayez pas à vous préoccuper des rôles FSMO, il est toujours important de comprendre comment ils fonctionnent lorsque le moment arrive !