Rôles de maître d'opérations
Active Directory prend en charge la réplication MultiMaster du magasin de données de l'annuaire parmi tous les contrôleurs de domaine du domaine, de sorte que tous les contrôleurs de domaine d'un domaine sont essentiellement égaux. Toutefois, certaines modifications ne peuvent pas être effectuées avec la réplication MultiMaster. Pour ces types de modifications, un seul contrôleur de domaine appelé maître d'opérations accepte les demandes.
Dans toute forêt, au moins cinq rôles de maître d'opérations sont attribués à un ou à plusieurs contrôleurs de domaine. Les rôles de maître d'opérations à l'échelle de la forêt ne doivent apparaître qu'une seule fois dans chaque forêt. Les rôles de maître d'opérations à l'échelle du domaine doivent apparaître une fois dans chaque domaine de la forêt.
Remarques
-
Les rôles de maîtres d'opérations sont parfois appelés rôles FSMO (Flexible Single Master Operations).
Rôles de maître d'opérations à l'intérieur d'une forêt
Chaque forêt doit avoir les rôles suivants :
-
Contrôleur de schéma
-
Maître d'attribution de noms de domaine
Ces rôles doivent être uniques à l'intérieur de la forêt. En d'autres termes, il ne peut exister qu'un contrôleur de schéma et un maître d'attribution de noms de domaine sur l'ensemble de la forêt.
Contrôleur de schéma
Le contrôleur de domaine doté du rôle de contrôleur de schéma contrôle toutes les mises à jour et modifications du schéma. Pour mettre à jour le schéma d'une forêt, vous devez accéder au contrôleur de schéma. Il ne peut exister qu'un seul contrôleur de schéma sur l'ensemble de la forêt.
Maître d'attribution de noms de domaine
Le contrôleur de domaine qui joue le rôle de maître d'attribution de noms de domaine contrôle l'ajout ou la suppression de domaines dans la forêt. Il ne peut exister qu'un seul maître d'attribution de noms de domaine sur l'ensemble de la forêt.
Remarques
-
Tout contrôleur de domaine exécutant Windows Server 2003 peut détenir le rôle de maître d'attribution de noms de domaine. Un contrôleur de domaine exécutant Windows 2000 Server qui détient le rôle de maître d'attribution de noms de domaine doit également être activé comme serveur de catalogues global.
Rôles de maître d'opérations à l'intérieur d'un domaine
Chaque domaine de la forêt doit avoir les rôles suivants :
-
Maître des ID relatifs (RID, Relative ID)
-
Maître d'émulateur du contrôleur principal de domaine (PDC)
-
Maître d'infrastructure
Ces rôles doivent être uniques à l'intérieur de chaque domaine. En d'autres termes, il ne peut exister qu'un maître RID, un maître d'émulateur PDC et un maître d'infrastructure dans chaque domaine de la forêt.
Maître RID
Le maître RID alloue des séquences d'ID relatifs (RID) à chacun des différents contrôleurs de domaine de son domaine. À tout moment, il ne peut exister qu'un seul contrôleur de domaine jouant le rôle de maître RID dans chaque domaine de la forêt.
Quand un contrôleur de domaine crée un utilisateur, un groupe ou un ordinateur, il assigne à cet objet un ID de sécurité (SID, Security ID) unique. Le SID se compose d'un SID de domaine qui est identique pour tous les SID créés dans le domaine et d'un ID relatif (RID) qui est unique pour chaque SID créé dans le domaine.
Pour déplacer un objet entre les domaines (à l'aide de Movetree.exe), vous devez commencer le déplacement sur le contrôleur de domaine qui joue le rôle de maître RID pour le domaine où se trouve actuellement l'objet.
Maître d'émulateur PDC
Si le domaine contient des ordinateurs qui n'utilisent pas le logiciel client Windows 2000 ou Windows XP Professionnel, ou s'il contient des contrôleurs secondaires de domaine (BDC) Windows NT, le maître d'émulateur PDC joue le rôle de contrôleur principal de domaine Windows NT. Il traite les modifications de mot de passe des clients et réplique les mises à jour sur les contrôleurs secondaires de domaine. À tout moment, il ne peut exister qu'un seul contrôleur de domaine jouant le rôle de maître d'émulateur PDC dans chaque domaine de la forêt.
Par défaut, le maître d'émulateur PDC est également chargé de synchroniser l'heure sur tous les contrôleurs de domaine du domaine. L'horloge de l'émulateur PDC d'un domaine est réglée sur celle d'un contrôleur de domaine arbitraire du domaine parent. L'émulateur PDC du domaine parent doit être configuré pour synchroniser son horloge avec une source de temps externe. Vous pouvez synchroniser l'heure de l'émulateur PDC avec un serveur externe en exécutant la commande « net time » conformément à la syntaxe suivante :
net time \\NomServeur/setsntp:SourceHeure
Le résultat final est que tous les ordinateurs de la forêt qui exécutent Windows Server 2003 ou Windows 2000 sont à la même heure, à quelques secondes près.
L'émulateur PDC reçoit en priorité la réplication des changements de mot de passe effectués par d'autres contrôleurs de domaine du domaine. Si un mot de passe a été modifié récemment, cette modification n'est pas répliquée immédiatement sur chaque contrôleur de domaine du domaine. Si une authentification d'ouverture de session échoue sur un contrôleur de domaine à cause d'une erreur de mot de passe, ce contrôleur de domaine transmettra la demande d'authentification à l'émulateur PDC avant de refuser la tentative d'ouverture de session.
Le contrôleur de domaine configuré avec le rôle d'émulateur PDC prend en charge deux protocoles d'authentification :
-
le protocole Kerberos V5
-
le protocole NTLM
Maître d'infrastructure
À tout moment, il ne peut exister qu'un seul contrôleur de domaine jouant le rôle de maître d'infrastructure dans chaque domaine. Le maître d'infrastructure est responsable de la mise à jour des références des objets de son domaine sur les objets des autres domaines. Le maître d'infrastructure compare ses données à celles du catalogue global. Les catalogues globaux reçoivent des mises à jour régulières des objets de tous les domaines par le biais de réplications. Les données du catalogue global sont ainsi actualisées en permanence. Si le maître d'infrastructure trouve des données qui ne sont pas à jour, il demande les données mises à jour à un catalogue global. Le maître d'infrastructure réplique ensuite les données mises à jour sur les autres contrôleurs de domaine du domaine.
Important
-
Le rôle de maître d'infrastructure ne doit pas être attribué au contrôleur de domaine qui héberge le catalogue global, sauf si le domaine ne comporte qu'un seul contrôleur de domaine. Si le maître d'infrastructure et le catalogue global sont situés sur le même contrôleur de domaine, le maître d'infrastructure ne fonctionnera pas. Le maître d'infrastructure ne trouvera jamais des données non actualisées et ne répliquera donc jamais les modifications sur les autres contrôleurs de domaine du domaine.
Dans le cas où tous les contrôleurs de domaine d'un domaine hébergent également le catalogue global, ils disposent tous des données actualisées, quel que soit le contrôleur de domaine qui joue le rôle de maître d'infrastructure.
Le maître d'infrastructure est également responsable de la mise à jour des références groupe-utilisateur chaque fois que les membres des groupes sont renommés ou modifiés. Lorsque vous renommez ou déplacez un membre d'un groupe (et si ce membre réside dans un domaine différent de celui du groupe), ce membre peut ne pas apparaître temporairement dans ce groupe. Le maître d'infrastructure du domaine du groupe est responsable de la mise à jour du groupe. Par conséquent, il connaît le nouveau nom ou le nouvel emplacement du membre. Cela permet de ne pas perdre les informations d'appartenance aux groupes associées aux comptes d'utilisateur lorsque ces derniers sont renommés ou déplacés. Le maître d'infrastructure distribue la mise à jour via la réplication MultiMaster.
La sécurité n'est pas compromise pendant le délai compris entre la modification du nom du membre et la mise à jour du groupe. Seul un administrateur qui observe cette appartenance au groupe spécifique remarquera l'incohérence temporaire.
Pour plus d'informations sur le transfert des rôles de maître d'opérations, voir Transfert des rôles de maître d'opérations. Pour plus d'informations sur la procédure à suivre en cas d'échec du maître d'opérations, voir Réponse aux échecs du maître d'opérations.