Dans une infrastructure Active Directory (AD) tous les contrôleurs de domaine sont équivalents. Cela signifie que chaque modification apportée à votre base de données AD est automatiquement répliquée sur tous les autres contrôleurs de domaine (DC), c’est le mode dit de multi maitre. Tous les contrôleurs sont synchronisés et chacun peut apporter une modification. Il n’y a plus de notion maitre esclave.

Cependant, une architecture où tous les acteurs sont capables de décider et d’échanger les informations entre eux pose un problème : Comment être sûr de l’intégrité de certaines données nécessaire au bon fonctionnement du système ? Certains paramètres doivent être uniques dans votre infrastructure et un seul DC doit avoir le contrôle dessus.

Prenons l’exemple de l’heure, si le décalage entre le client et le contrôleur de domaine est supérieur à cinq (5) minutes, Kerberos refusera l’authentification du client. Or si deux DC ont des heures systèmes différentes, qui prendra le dessus sur l’autre, lequel fera office de Network Time Protocol (NTP) ? Un DC doit donc être désigné pour assurer seul ce rôle.

C’est pour résoudre ces différents problèmes que Microsoft a mis en place les rôles maitres d’Active Directory. Vous les avez peut-être déjà rencontrés avec des noms différents : Operations Master, Single Master Roles, Operations Tokens ou encore Flexible Single Master Operations (FSMO).

Nous verrons dans un premier temps les cinq différents rôles qui existent pour le service d’annuaire Active Directory, puis dans un second temps, comment les identifier.

La notion d’Operation Master

Un DC qui assume un rôle dit d’Operation Master est donc le seul responsable dans la forêt ou le domaine à effectuer des actions sur des données sensibles.

Active Directory Domaine Services possède 5 maitres d’opérations que l’on peut séparer en deux catégories : ceux qui agissent sur la Forêt et ceux qui agissent sur le Domaine. Deux rôles agissent sur la forêt tandis que 3 autres rôles agissent sur le domaine. Dans chacun de vos domaines se trouvent les trois rôles. Si vous avez dans votre architecture deux domaine, alors il existe huit operations master au total (2 pour la forêt, 3 pour le domaine A et 3 pour le domaine B).

Bien sûr, il n’est pas nécessaire d’avoir autant de DC que de rôles, un contrôleur de domaine peut très bien gérer plusieurs rôles simultanément.

Les Operations Masters de la Forêt

Il existe deux rôles maitres pour la forêt : Schema master et Domain Naming Master. Ils doivent être uniques dans votre forêt. Chaque rôle est assuré par un seul domaine contrôleur.

• Schema Master : Le contrôleur de domaine qui détient le rôle de maitre de schéma est responsable de tous les changements qui peuvent se produire sur le schéma de la forêt. Tous les autres domaines contrôleurs sont des réplicas en mode lecture seule (Read only). Les applications qui peuvent changer les propriétés d’un objet dans le schéma, comme Microsoft Exchange, envoient leurs requêtes au maitre d’opération Schéma de la forêt. Lorsque ce serveur est indisponible, il est alors impossible de modifier le schéma.

• Domain Naming Master : le contrôleur qui gère le rôle de maitre de nom de domaine est responsable de l’ajout et la suppression d’un domaine. Il vérifie également si un autre domaine ne porte pas le même nom. Si celui-ci est indisponible pendant la création d’un nouveau domaine,  il sera alors impossible de joindre le nouveau domaine à la forêt.

Les Operations Master du domaine

Chaque domaine contient trois masters rôles. Le rôle d’infrastructure, le PDC Emulator et enfin le RID. Comme les rôles de la forêt, un rôle doit être unique dans le domaine.

• RID Master (Relative Identifier) : Lorsque vous ajouter un utilisateur, un ordinateur, un groupe, etc… à votre base Active Directory, celui-ci est identifié par un SID. Le SID doit être unique dans le domaine. Pour assurer les ACL par exemple. Si chaque domaine contrôleur décide du SID qu’il va créer, alors comment être certain qu’un autre DC n’a pas déjà donné ou va donner le même. Il est donc nécessaire de mettre un place un mécanisme pour assurer l’unicité du SID. C’est là qu’intervient le rôle RID Master. Le DC qui en est responsable va générer un pool d’unique SID pour chaque DC du domaine. Ainsi, chaque DC pourra être certain de son SID. Le RID Master est comme un DHCP pour SID.

• Infrastructure Master : Dans un environnement multi domaine, on peut faire appel à des objets situés dans un autre domaine. Prenons l’exemple d’un groupe, un groupe peut inclure des utilisateurs du domaine, mais aussi des utilisateurs d’autre domaine. Mais lorsque le domaine distant ne vous appartient pas, comment être sur que l’utilisateur distant n’a pas été déplacé ou supprimé. Cela aura pour effet d’avoir des objets fantômes dans votre groupe. Le rôle d’infrastructure maintient donc à jour les relations extérieures au domaine. Il identifie les changements et fait les modifications pour garder à jour nos membres du groupe.

• PDC Emulator : Le Primary Domain Controller exécute plusieurs fonctions importantes ou  cruciales pour le domaine. Il regroupe 4 opérations.

Dans un premier temps, pour garder la compatibilité avec Windows NT 4 et ses différents outils / Applications , il émule un Primary Domain Controleur. Sous NT4 seuls les PDC pouvaient faire des changements sur la base de données.

Le DC qui possède le rôle de PDC participe activement dans la mise à jour des mots de passes utilisateurs : Quand un mot de passe utilisateur est changé ou réinitialisé par l’administrateur, alors le DC qui a effectué la modification réplique immédiatement le changement vers le PDC du domaine. Cela assure la bonne connaissance des mots de passe entre tous les contrôleurs du domaine même si la réplication n’a pas encore eu lieu.  Si un utilisateur essaye d’ouvrir une session sur le domaine juste après le changement de son mot de passe et que la réplication n’a pas été effectué alors le contrôleur du site distant ne verra pas la correspondance entre les mots de passe. Pour avoir un second avis avant de refuser l’authentification, le contrôleur du site va demander au PDC de vérifier le mot de passe. Comme le PDC connait le nouveau mot de passe, il acceptera la demande d’ouverture. Attention, cela signifie qu’à chaque fois qu’un utilisateur se trompe de mot de passe, l’authentification est transmise au PDC. Il doit donc avoir une haute disponibilité ainsi qu’une bonne connexion.

Le PDC gère également les mises à jour des GPO. Si la gestion des GPO n’était pas centralisée sur un serveur unique,  il pourrait y avoir conflit lorsque deux administrateurs modifient la GPO simultanément au moment de la réplication. Par défaut, lorsque vous faites une modification sur l’objet, vous faites la modification sur le SYSVOL du PDC et la réplication s’occupe du reste.

Une fonction primordiale d’Active Directory est également gérée par le PDC : la gestion du temps horaire du réseau. En effet, Active Directory, Kerberos et la réplication des fichiers se basent sur l’heure pour fonctionner.  Les DC du domaine synchronisent tous leur heure sur le PDC. Tous les autres membres du domaine, comme les ordinateurs et serveurs se synchronisent sur leur DC respectif.

Le PDC est le rôle qui aura le plus d’impact s’il devient indisponible.

Identification des serveurs

Il est très utile de savoir quel serveur occupe les rôles vu ci-dessus dans votre infrastructure. Pour améliorer les performances ou prévoir un plan de secours en cas de défaillance.

Pour identifier l’actuel operation master de chaque rôle, utilisez les outils suivants :

• PDC, RID et Infrastructure : Active Directory Users and Computers.

• Domain Naming : Active Directory Domains And Trusts.

• Schema Master : Active Directory Schema.

Vous pouvez également lister les rôles avec ntdsutils, dcdiag ou netdom.

Pour ntdsutils :

Roles

Connections

Connect to server <Your DCFQDN>

Quit

Select operation target

List roles for connected server

Pour dcdiag:

Dcdiag /test:knowsofroleholders /v

Pour netdom:

Netdom query fsmo

Conclusion

Nous venons de voir que même si Active Directory est multi maitre, il n’empêche en rien que certains contrôleurs de domaine soient plus importants que d’autre dans le bon fonctionnement du système. Veillez à toujours avoir un plan d’action au cas où les maitres d’opérations seraient indisponibles pour maintenance ou pour défaillance. D’autre part, il est vivement conseillé d’avoir au moins deux DC par site.

• Entrée précédente: La réplication sous Exchange 2007
• Entrée suivante: Transfert des Operations Master