Rôles FSMO dans Active Directory: Ce qu’ils sont et comment ils fonctionnent

Active Directory (AD) est un service d’annuaire créé par Microsoft, et il se présente sous la forme d’un ensemble de processus et de services dans la plupart des versions des systèmes d’exploitation Windows Server.

Vous pouvez imaginer AD comme une base de données ou un emplacement sécurisé qui stocke tous les attributs de vos utilisateurs tels que les noms d’utilisateur, les mots de passe, etc. Ce référentiel central automatise de nombreuses tâches telles que la gestion des données utilisateur, la sécurité et les inter-opérations avec d’autres répertoires.

Dans les versions initiales de AD, il y avait beaucoup de risques de conflits. Par exemple, disons qu’un contrôleur de domaine a ajouté un nouvel employé à la base de données. Depuis que le changement a été apporté à l’annonce, il a été reflété dans toute l’entreprise, et c’est très bien. Quelques secondes plus tard, un autre contrôleur de domaine voulait supprimer les enregistrements des employés qui ne travaillaient plus dans l’entreprise. Accidentellement, il a également supprimé cet employé de l’ANNONCE.

Le système de gestion des conflits qui existait alors suivait la stratégie ” last writer wins “, de sorte que la modification apportée par le deuxième contrôleur de domaine était valide tandis que la modification apportée par le premier contrôleur de domaine était ignorée. Cela signifie que le nouvel employé n’était plus dans le système et ne pouvait pas accéder aux ressources du système, ce qui n’est évidemment pas correct.

Pour éviter de tels conflits, un modèle à maître unique a été introduit. Dans ce modèle, un seul contrôleur de domaine (DC) peut effectuer un type particulier de mise à jour. Dans le cas ci-dessus, si seul le premier DC était chargé d’ajouter et de supprimer des employés et le deuxième DC était chargé de la sécurité, un tel conflit ne se serait pas produit.

Cependant, cela comportait également des limites. Que se passe-t-il lorsque le premier DC tombe en panne? Vous ne pouvez pas ajouter ou supprimer d’employés jusqu’à ce qu’il revienne. Une telle dépendance vis-à-vis d’un seul contrôleur n’est jamais bonne du point de vue opérationnel.

Ainsi, Microsoft est allé un peu plus loin dans les versions suivantes pour inclure plusieurs rôles pour chaque DC et pour donner à chaque DC la possibilité de transférer l’intégralité du rôle à n’importe quel autre DC au sein de la même entreprise. L’avantage évident ici est qu’aucun rôle n’est lié à un DC particulier, donc lorsque l’un descend, vous pouvez transférer automatiquement ce rôle à un autre DC fonctionnel.

Comme un tel modèle offre beaucoup de flexibilité, on l’appelle l’opération flexible Single Master (FSMO).

En effet, FSMO est un modèle multimaster qui attribue des rôles et des responsabilités clairs à chaque DC tout en offrant la flexibilité nécessaire pour transférer des rôles si nécessaire.

Rôles FSMO

Le FSMO est largement divisé en cinq rôles et ils sont:

• Maître de schéma
• Maître de nommage de domaine
• Maître RID
• Émulateur PDC
• Maître d’infrastructure

Parmi ceux-ci, les deux premiers rôles FSMO sont disponibles au niveau de la forêt tandis que les trois autres sont nécessaires pour chaque domaine.

Extensions distantes

Examinons maintenant chaque rôle FSMO en profondeur.

Maître de schéma

Maître de schéma, comme son nom l’indique, contient une copie en lecture-écriture de l’ensemble du schéma de votre ANNONCE. Si vous vous demandez ce qu’est un schéma, il s’agit de tous les attributs associés à un objet utilisateur et comprend le mot de passe, le rôle, la désignation et l’identifiant de l’employé, pour n’en nommer que quelques-uns.

Donc, si vous voulez changer l’identifiant de l’employé, vous devrez le faire dans ce DC. Par défaut, le premier contrôleur que vous installez dans votre forêt sera le maître de schéma.

Domain naming master

Domain naming master est responsable de la vérification des domaines, il n’y en a donc qu’un pour chaque forêt. Cela signifie que si vous créez un tout nouveau domaine dans une forêt existante, ce contrôleur garantit qu’un tel domaine n’existe pas déjà. Si votre maître de nommage de domaine est en panne pour une raison quelconque, vous ne pouvez pas créer de nouveau domaine.

Comme vous ne créez pas souvent de domaines, certaines entreprises préfèrent avoir le maître de schéma et le maître de nommage de domaine dans le même contrôleur.

RID master

Chaque fois que vous créez un principe de sécurité, qu’il s’agisse d’un compte utilisateur, d’un compte de groupe ou d’un compte maître, vous souhaitez y ajouter des autorisations d’accès. Mais vous ne pouvez pas le faire en fonction du nom d’un utilisateur ou d’un groupe car cela peut changer à tout moment.

Disons que vous aviez Andy avec un rôle particulier, et il a quitté l’entreprise. Donc, tu as fermé le compte d’Andy et tu as fait venir Tim. Maintenant, vous devrez remplacer Andy par Tim dans les listes d’accès de sécurité de chaque ressource.

Ce n’est pas pratique, car cela prend du temps et est sujet aux erreurs.

C’est pourquoi vous associez chaque principe de sécurité à quelque chose appelé ID de sécurité ou SID. De cette façon, même si Andy change en Tim, le SID restera le même, vous devrez donc effectuer un seul changement.

Ce SID a un modèle spécifique pour garantir que chaque SID du système est unique. Il commence toujours par la lettre “S” suivie de la version (commence par 1) et d’une valeur d’autorité d’identification. Il est suivi du nom de domaine ou d’ordinateur local commun à tous les SID situés dans le même domaine. Enfin, le nom de domaine est suivi de ce qu’on appelle un ID relatif ou RID.

Essentiellement, RID est la valeur qui assure l’unicité entre les différents objets dans active directory.

Un SID ressemblera à ceci : S-1-5-32365098609486930-1029 . Ici, 1029 est le RID qui rend un SID unique tandis que la longue série de nombres est votre nom de domaine.

Mais cela peut également entraîner des conflits. Disons que nous créons deux comptes d’utilisateurs en même temps. Cela peut provoquer des conflits car il est possible que ces deux objets aient le même SID.

Pour éviter ce conflit, le maître RID attribue des blocs de 500 à chaque contrôleur de domaine. De cette façon, DC1 obtient des RIDs de 1 à 500, DC2 obtient des RIDs de 501 à 1 000, et ainsi de suite. Lorsqu’un contrôleur de domaine manque de RID, il contacte le maître RID et, à son tour, ce maître RID attribue un autre bloc de 500.

Ainsi, le maître RID est responsable du traitement des demandes de pool RID des CD dans un seul domaine pour s’assurer que chaque SID est unique.

Émulateur PDC

PDC signifie Contrôleur de domaine principal et il vient d’une époque où un seul contrôleur de domaine possédait une copie en lecture-écriture du schéma. Les contrôleurs de domaine restants étaient une sauvegarde pour ce PDC. Donc, si vous vouliez changer un mot de passe, vous deviez vous rendre au PDC.

Aujourd’hui, il n’y a plus de PDC. Mais certains de ses rôles comme la synchronisation de l’heure et la gestion des mots de passe sont repris par un contrôleur de domaine appelé émulateur PDC.

Regardons d’abord sa gestion des mots de passe.

Disons que je vais sur un contrôleur de domaine et que je réinitialise mon mot de passe car il a expiré. Ensuite, je me connecte à une autre machine pour un site différent et, disons, elle contacte un contrôleur de domaine différent pour l’authentification. Il est possible que ma connexion échoue car le premier contrôleur de domaine n’a peut-être pas répliqué mon changement de mot de passe à d’autres contrôleurs.

Un émulateur PDC évite ces confusions en étant le contrôleur pour les réinitialisations de mot de passe. Ainsi, mon client contactera l’émulateur PDC lorsqu’une connexion échoue, pour vérifier s’il y a eu un changement de mot de passe. De plus, tous les verrouillages de compte dus à des mots de passe erronés sont traités sur cet émulateur PDC.

Autre que la gestion des mots de passe, l’émulateur PDC synchronise l’heure dans un système d’entreprise. C’est une fonctionnalité importante car l’authentification AD utilise un protocole appelé kerberos pour la sécurité. La tâche principale de ce protocole est de s’assurer que les paquets de données ne sont pas retirés du réseau ou falsifiés pendant leur transmission.

Ainsi, lorsqu’il y a une différence de cinq minutes ou plus entre l’horloge d’un serveur et votre système pendant le processus d’authentification, kerberos pense qu’il s’agit d’une attaque et ne vous authentifiera pas.

Très bien, mais quel est le rôle d’un émulateur PDC ici?

Eh bien, votre système local synchronise son temps avec le contrôleur de domaine, et le contrôleur de domaine, à son tour, synchronise son temps avec l’émulateur PDC. De cette façon, l’émulateur PDC est l’horloge principale de tous les contrôleurs de domaine de votre domaine.

Lorsque ce contrôleur est en panne, votre sécurité diminue de quelques crans et rend les mots de passe vulnérables aux attaques.

Maître d’infrastructure

La fonctionnalité de base d’un maître d’infrastructure est de référencer tous les utilisateurs et références locaux dans un domaine. Ce contrôleur comprend l’infrastructure globale du domaine, y compris les objets qui y sont présents.

Il est responsable de la mise à jour locale des références d’objets et s’assure également qu’elles sont à jour dans les copies des autres domaines. Il gère ce processus de mise à jour via un identifiant unique, éventuellement un SID.

Infrastructure master est similaire à un autre outil publicitaire appelé Global Catalog (GC). Ce GC est comme un index qui sait où tout se trouve, à l’intérieur d’un active directory. L’infrastructure master, en revanche, est une version plus petite de GC, car elle est restreinte dans un seul domaine.

Maintenant, pourquoi est-il important de connaître GC ici? Parce que GC et infrastructure master ne doivent pas être placés dans le même contrôleur de domaine. Si vous faites cela, le maître d’infrastructure cessera de fonctionner lorsque le GC aura la priorité.

En général, si vous n’avez qu’un seul contrôleur de domaine, cela n’aura pas tellement d’importance. Mais, si vous avez une grande forêt avec plusieurs contrôleurs de domaine, la présence de GC et d’infrastructure master posera des problèmes.

Prenons une situation ici. Nous avons plusieurs domaines qui recherchent un serveur GC. Dans un domaine, nous apportons une modification à l’appartenance au groupe et le maître d’infrastructure est au courant de cette modification. Mais il ne met pas à jour le serveur GC car la modification n’a pas été apportée à un groupe universel. Cela signifie que votre GC et votre maître d’infrastructure risquent de ne pas être synchronisés, ce qui peut entraîner des problèmes d’authentification. C’est pourquoi assurez-vous d’avoir un maître d’infrastructure ou un GC pour chaque domaine, mais pas les deux.

Résumé

Comme vous pouvez le voir. Les rôles FSMO empêchent les conflits dans un active directory et, en même temps, vous donnent la flexibilité de gérer différentes opérations au sein d’Active directory. Ils peuvent être divisés en cinq rôles, dont les deux premiers concernent l’ensemble de la forêt tandis que les trois autres concernent un domaine particulier.

Avez-vous implémenté des rôles FSMO dans votre organisation ? Veuillez nous faire part de vos réflexions.

Crédit photo: Wikimédia