A propos des rôles FSMO

Une infrastructure Active Directory fonctionne par défaut en mode multi-maître. Le principal avantage est qu’il est possible de faire un changement sur l’infrastructure Active Directory depuis n’importe quel contrôleur de domaine.

Ce type d’architecture entraîne un risque de conflit entre les différents contrôleurs de domaines lors de la réplication entre les différents contrôleurs de domaine. Le système de réplication Active Directory a plusieurs stratégie pour résoudre les conflits potentiels, mais il y a certaines tâches critiques qui ne peuvent pas être partagées.

Il y a des rôles FSMO qui sont uniques sur un même domaine, et des rôles qui sont uniques sur la forêt Active Directory. Vu que Samba ne supporte pas actuellement les forêts multi-domaine, en pratique il n’y a qu’un serveur qui a le rôle en question dans la forêt mono-domaine Samba.

Pour ces tâches, un mode à maître unique est utilisé. Ces maîtres uniques sont réparties en 5 principaux rôles FSMO plus 2 autres rôles de moindre importance :

Contrôleur de schéma.
Maître de nommage de domaine.
Maître RID.
Emulateur de contrôleur de domaine.
Maître d’infrastructure.

Dans les documentations Active Directory de Microsoft, uniquement les cinq rôles ci-dessus sont mentionnés. Le détenteur de chacun de ses rôles est défini dans la LDAP Active Directory à travers les attributs fSMORoleOwner. Pour l’exhaustivité, il existe deux attributs fSMORoleOwner sur les partitions DC=DomainDNSZones et DC=ForestDNSZones. Samba mentionne également ces deux rôles supplémentaires dans les différentes interfaces :

maître d’infrastructure DomainDnsZones ;
Maître d’infrastructure (ForestDnsZones).

Les sections suivantes vont expliquer plus en détail la fonction de chacun de ces rôles, dans l’ordre d’importance pratique.

La littérature accorde habituellement beaucoup d’importance à ces rôles FSMO, avec des préconisations pour « équilibrer » les rôles et beaucoup d’autres actions ésotériques. En pratique, on peut les laisser sur un serveur central du domaine Samba-AD, et ne pas s’en soucier. Dans une topologie de réplication en étoile, on mettra les rôles FSMO sur un des serveurs du centre de l’étoile.

Il faut faire attention aux rôles que si le serveur qui détient tous les rôles FSMO va être décommissionné ou éteint pour une longue durée.

Dans le cas où le serveur avec les rôles FSMO va être éteint ou mis hors d’usage, il faut effectuer un transfert des rôles sur un autre des serveurs. Si le serveur avec les rôles FSMO est défaillant et ne peut pas être redémarré, il faut faire un seize des rôles sur un autre serveur. Le seize fait la même chose que le transfert, mais dans ce deuxième cas il s’accapare les rôles sans demander au serveur qui les avaient au préalable.

Le transfer des rôles est une action simple qui ne pose pas de problème particulier.

Rôle de Maître RID

Chaque object utilisateur, groupe et machine du domaine est identifié par un RID (cf. la section Winbind). Le RID doit être unique sur l’ensemble d’un domaine, alors que l’on peut créer un nouvel object sur n’importe lequel des contrôleurs de domaine.

Pour éviter les conflits, Microsoft a imaginé un système de pool de RID disjoint sur chacun des contrôleurs de domaine. Ainsi le premier contrôleur aura le pool 1000-1499 (500 RID). Lorsque l’on va joindre le deuxième contrôleur de domaine, il aura le pool suivant disponible (1500-1999). Le troisième contrôleurs de domaine aura le prochain pool disponible (2000-2499, ou bien une autre tranche si cette tranche a déjà été attribuée à un autre contrôleur de domaine).

Le serveur qui est responsable de fournir les pool de RID détient le rôle FSMO RID.

Quand un contrôleur de domaine arrive à 80% d’utilisation de son pool (soit 400 RID utilisé), il fait une demande au FSMO RID pour obtenir un nouveau pool. Le rôle FSMO RID lui donnera alors le prochain pool disponible, et notera qu’il a été attribué.

Ainsi, les RID des utilisateurs ne se suivent pas s’ils n’ont pas été créés sur le même contrôleur de domaine. Par exemple sur le premier contrôleur, un nouvel utilisateur aura le RID 1001, alors que sur le deuxième il aura le RID 1501, alors qu’ils ont été créés l’un après l’autre.

Si un contrôleur de domaine a épuisé son pool de RID et n’arrive pas à contacter le serveur avec le rôle FSMO RID, il ne pourra pas créer un nouvel object. Le message d’erreur en cas d’épuisement du pool n’est pas explicite sur les outils RSAT (« le serveur refuse d’exécuter la demande »), mais il est très explicite en ligne de commande samba-tool (no RID left).

Note

Il n’y a qu’un seul Maître RID par domaine.

Rôle PDC (émulateur de contrôleur de domaine)

Lors de conception d’Active Directory 2000, Microsoft a conçu une méthode simple de migration des domaines NT4 vers la technologie Active Directory. Lors de la migration d’un domaine NT4 avec plusieurs contrôleurs de domaine, la procédure était de mettre à jour le serveur PDC avant de mettre à jour les BDC.

Dans la phase intermédiaire où le PDC était migré en Active Directory, mais que les BDC étaient toujours en mode NT4, il était nécessaire d’assurer la réplication du nouvel AD vers les BDC NT4. Le premier contrôleur de domaine migré, le PDC, gardait donc le rôle PDC de réplication vers les BDC.

De nos jours, les contrôleurs de domaine, Microsoft ou Samba, ne supportent plus cette fonction de synchronisation PDC-BDC NT4. Néanmoins, le nom est resté.

Le contrôleur détenant le rôle d’Émulateur de contrôleur de domaine a désormais plusieurs fonctions :

Il gère le changement de mot de passe. Lors d’un changement de mot de passe, le serveur avec le rôle FSMO PDC va recevoir en priorité le changement de mot de passe. Si un contrôleur de domaine gère une authentification qui échoue, il va demander au serveur avec le rôle PDC s’il n’a pas eu une mise à jour du mot de passe entre temps, car il n’a peut être pas encore répliqué le changement de mot de passe qui a pu avoir été initié depuis un autre site géographiquement éloigné.
Il gère la synchronisation du temps avec les postes : il est le maître NTP.
Il gère le verrouillage des comptes.

Note

Il n’existe qu’un seul Émulateur de contrôleur de domaine par domaine Active Directory.

Contrôleur de schéma

Le contrôleur de domaine détenant ce rôle est le seul à pouvoir mettre à jour les schémas Active Directory. Une fois ces schémas mis à jour, il les réplique vers tous les contrôleurs de domaine. Ces schémas se trouvent dans chaque DC et sont localisés dans la LDAP dans CN=schema,CN=configuration,DC=<domain>.

Note

Il n’y a qu’un seul Contrôleur de schéma par forêt Active Directory.

Maître de nommage de domaine

Le contrôleur de domaine détenant ce rôle est le seul à gérer la création / suppression de domaine au sein de la forêt.

Cela sous-entend qu’il gère aussi la création / suppression des relations d’approbation entre les différents domaines et qu’il réplique ces informations vers tous les contrôleurs de domaine de la forêt.

Ces informations sont stockées dans la LDAP de chaque contrôleur de domaine dans la partition Configuration Naming Context se trouvant dans CN=Partitions,CN=Configuration,DC=<domain>.

Note

Il n’y a qu’un seul Maître de nommage de domaine par forêt Active Directory.

Maître d’infrastructure

Le contrôleur de domaine possédant le rôle de Maître d’infrastructure est responsable de la mise à jour des objets SID et noms distinctifs dans une référence d’objets inter-domaines, par exemple si un utilisateur d’un domaine X est ajouté à un groupe d’un autre domaine Y.

Note

Le rôle infrastructure ne doit pas être sur un contrôleur de domaine ayant aussi le Global Catalog (voir doc LDAP) dans une forêt multi-domaines. Samba ne supportant uniquement les forêts mono-domaine, ce n’est pas un soucis.

Note

Il n’y a qu’un seul Maître d’infrastructure par domaine Active Directory.