Contrôleurs de domaine et les cinq rôles FSMO

Un répertoire grandit en contrôleurs, et dès qu'il y en a plus d'un apparaissent des décisions que tous ne peuvent pas prendre en même temps : qui approuve un changement de schéma, quel domaine vient d'être créé, à quel contrôleur arrive en premier le mot de passe que quelqu'un a changé à trois heures du matin. Dans AD DS, ces décisions ont un propriétaire. Ce post parcourt comment on monte un contrôleur de domaine, ce que couvre la corbeille de restauration et ce qu'elle ne couvre pas, où se loge le catalogue global et ce que fait chacun des cinq rôles d'opérations maîtres (FSMO, flexible single master operations). Ce qui suit vient du module « Administer AD DS domain controllers and FSMO roles » de Microsoft Learn.

Monter un contrôleur, en deux étapes

La première étape installe les binaires d'AD DS, depuis Windows Admin Center avec le module AD DS ou depuis le gestionnaire de serveurs. La seconde configure avec l'assistant de configuration d'AD DS, qui pose les questions qui décident du rôle du serveur : s'il sera le premier contrôleur de la forêt, un nouvel arbre ou un contrôleur supplémentaire ; le FQDN DNS ; les niveaux fonctionnels de forêt et de domaine ; le serveur DNS ; s'il hébergera le catalogue global (activé par défaut) ; s'il sera RODC (pas disponible pour le premier contrôleur, et pensé pour les agences avec une sécurité physique faible) ; et le mot de passe du mode de restauration des services de répertoire (DSRM), celui qu'il faut pour entrer si le répertoire tombe.

La recommandation est directe : au minimum deux contrôleurs de domaine par région géographique. Un contrôleur par site, c'est une seule vérité par lieu, et n'importe quelle maintenance devient une fenêtre de risque.

Le scénario qui donne du contexte à ces règles est celui de toujours : une entreprise qui migre des serveurs Windows Server 2012 R2 vers 2025, ouvre de nouvelles agences géographiques et virtualise ses contrôleurs. Chaque nouvelle agence relance les mêmes questions : combien de contrôleurs tiennent dans la région, où vit le catalogue global et quel rôle revient à quel serveur pendant que l'infrastructure bouge.

Dans Azure la liste change un peu : un site AD DS par plage d'adresses dans la vnet, des serveurs avec IP statiques, NTDS.DIT et SYSVOL sur un disque de données avec la préférence de cache hôte sur AUCUNE (évite que le cache d'écriture local écrive de lui-même et désynchronise le fichier), et DNS résolu avec le rôle DNS de Windows Server ou les zones privées Azure DNS, car le DNS intégré d'Azure ne supporte pas les enregistrements SRV attendus par le répertoire.

Ce que couvre la corbeille de restauration (et ce qu'elle ne couvre pas)

La corbeille de restauration d'AD DS retient les objets supprimés 180 jours par défaut et permet de les restaurer sans temps d'indisponibilité. C'est la réponse à « j'ai supprimé la mauvaise UO » : au lieu de restaurer NTDS.DIT depuis une vieille copie, on récupère l'objet figé.

Ce qu'elle ne fait pas, c'est annuler les changements sur des objets existants. Si quelqu'un a renommé mille utilisateurs, la corbeille ne défait pas ça ; pour cela il y a la sauvegarde et la restauration traditionnelles.

Quand le dégât est plus grand, la pièce est la sauvegarde de l'état du système, et il y a deux chemins :

flowchart TD
    Q{Qu'est-il arrivé ?} --> A[Objet supprimé sans changements ultérieurs]
    Q --> B[Dégât plus grand ou suppression déjà répliquée]
    A --> P1[Corbeille : 180 jours, sans indisponibilité]
    B --> N1[Restauration non autoritative : la réplication gagne au redémarrage]
    B --> N2[Restauration autoritative : objets marqués avant de redémarrer]

Dans une restauration non autoritative, le contrôleur est éteint, restauré, et au redémarrage il récupère son état par la réplication, en rattrapant ses partenaires. C'est là la limite : une suppression postérieure à la sauvegarde mais déjà répliquée se réplique de nouveau, donc elle n'est pas récupérée. Dans une restauration autoritative, les objets restaurés sont marqués comme autoritatifs avant le redémarrage, et les autres contrôleurs répliquent depuis ce serveur.

Catalogue global : où l'héberger

Le catalogue global est une copie partielle, en lecture seule et interrogeable de tous les objets de la forêt, avec un sous-ensemble d'attributs par objet (givenName, displayName ou mail, entre autres). Partiel parce qu'il ne porte pas tous les attributs : il porte de quoi chercher dans toute la forêt sans la charger entière. Chaque objet de la forêt voyage vers tous les catalogues avec ce sous-ensemble, et le reste des attributs se consulte dans son domaine d'origine, ce qui maintient le trafic de réplication borné.

Dans une forêt à domaine unique, tous les contrôleurs l'hébergent et il n'y a rien à décider. Dans les forêts multidomaines, si : par où passe le catalogue définit comment le courrier est routé dans Exchange et comment l'authentification vérifie l'appartenance aux groupes universels. Et comme cela coûte aussi du trafic de réplication entre agences, on peut limiter son déploiement quand le volume s'accentue.

Les cinq rôles FSMO

AD DS est multi-maître : n'importe quel contrôleur accepte les écritures et les propage. Presque toutes. Environ cinq opérations ont besoin d'un seul responsable, et c'est pour cela que existent les rôles FSMO. Deux au niveau de la forêt et trois au niveau du domaine :

flowchart TD
    F[FSMO au niveau forêt] --> S[Maître de schéma]
    F --> N[Maître de nomenclature de domaines]
    D[FSMO au niveau domaine] --> R[Maître RID : attribue les blocs d'identifiants]
    D --> I[Maître d'infrastructure : références entre domaines]
    D --> P[Émulateur PDC : heure, mots de passe urgents, changements de GPO]

Maître de schéma. Le seul qui accepte les changements de schéma.
Maître de nomenclature de domaines (Domain Naming). Le responsable des noms de domaine au sein de la forêt.
Maître RID (identifiant relatif). Attribue des blocs d'identifiants relatifs à chaque contrôleur, ceux qui composent les SID des nouveaux objets.
Maître d'infrastructure. Entretient les références entre domaines. Sa clause fine : il ne doit pas résider sur un catalogue global sauf si tous les contrôleurs le sont.
Émulateur PDC. Le plus chargé : c'est la source d'heure du domaine (il se synchronise avec celle du domaine racine, qui utilise elle-même un serveur externe de confiance), il reçoit les changements de mot de passe urgents et, par défaut, les changements de GPO.

Le premier contrôleur de la forêt et le premier contrôleur de chaque domaine les hébergent tous. Pour voir qui a quoi en ce moment, Get-ADForest et Get-ADDomain renvoient les titulaires.

Quand un titulaire est sain mais qu'il faut déplacer le rôle, on le transfère à un autre contrôleur et les données les plus récentes voyagent avec lui. Quand le titulaire ne reviendra pas, on le saisit (seize), qui est le dernier recours et se paie avec la réplique la plus récente.

Le schéma, qui ne se touche qu'à un seul endroit

Le schéma définit tous les attributs et classes des objets, et sa copie se réplique sur tous les contrôleurs de la forêt. C'est pourquoi il n'accepte les changements que depuis le maître de schéma, depuis le domaine racine, et en étant membre du groupe Schéma Admins ; la console Schéma n'est pas enregistrée par défaut et il faut l'ajouter à la main.

Dans le schéma, les classes sont structurelles (les seules qui acceptent des objets) ou auxiliaires (elles ajoutent des attributs à d'autres classes). La classe utilisateur, par exemple, apporte plus de 400 attributs, dont cn et objectSid sont obligatoires. La taille du vocabulaire explique pourquoi on l'administre avec tant de précaution : un changement de schéma se réplique sur toute la forêt et presque personne ne le réinverse sans douleur.

Avec quoi on fait tout cela

Le quotidien se couvre avec Windows Admin Center plus le module AD DS, l'assistant de configuration lui-même et PowerShell : Get-ADForest et Get-ADDomain, entre autres cmdlets, renvoient les titulaires des rôles en une ligne. Pour toucher le répertoire au niveau de l'entrée, il y a ADSIEDIT.MSC, qui permet d'éditer directement le contenu du répertoire et qu'il vaut mieux garder en outil de dernier recours.

Ce qui se décide en premier

L'ordre de travail se tient tout seul : d'abord où vivent les contrôleurs (une région, deux contrôleurs, site et sous-réseau clairs), ensuite qui héberge le catalogue global, ensuite où tombent les cinq rôles FSMO, et le schéma en dernier et avec les permissions en main. À l'envers, cela produit des répertoires avec des rôles tombés sur des contrôleurs d'agence et des catalogues qui se répliquent en trop entre les sites.

Limite de cette source : elle décrit des procédures et des règles de placement, et n'apporte ni temps de convergence ni latences de réplication mesurés ; le dimensionnement concret d'une grande forêt reste donc impossible à juger ici.

*Source : le module « Administer AD DS domain controllers and FSMO roles » de Microsoft Learn.*