Planification de l’emplacement des rôles de maître d’opérations

Active Directory Domain Services (AD DS) prend en charge la réplication multimaître des données de répertoire, ce qui signifie que tout contrôleur de domaine peut accepter les modifications de répertoire et répliquer les modifications sur tous les autres contrôleurs de domaine. Toutefois, certaines modifications, telles que les modifications de schéma, ne sont pas pratiques à effectuer de manière multimaître. C’est pourquoi certains contrôleurs de domaine, appelés maîtres d’opérations, sont responsables de l’acceptation des demandes pour certaines modifications spécifiques.

Trois rôles de maître d’opérations (également appelés opérations à maître unique flottant ou FSMO) existent dans chaque domaine :

• Le contrôleur des opérations de l’émulateur de maître de domaine principal traite toutes les mises à jour de mot de passe.

• Le maître d’opérations RID (ID relatif) gère le pool RID global pour le domaine et alloue des pools RID locaux à tous les contrôleurs de domaine pour s’assurer que tous les principaux de sécurité créés dans le domaine ont un identificateur unique.

• Le maître des opérations d’infrastructure pour un domaine donné tient à jour une liste des principaux de sécurité d’autres domaines qui sont membres de groupes au sein de son domaine.

En plus des trois rôles de maître d’opérations au niveau du domaine, deux rôles de maître d’opérations existent dans chaque forêt :

• Le maître des opérations de schéma régit les modifications apportées au schéma.
• Le maître des opérations de nommage de domaine ajoute et supprime des domaines et d’autres partitions de répertoire (par exemple, des partitions d’application DNS [Domain Name System]) vers et depuis la forêt.

Placez les contrôleurs de domaine hébergeant ces rôles de maître d’opérations dans des zones où la fiabilité du réseau est élevée, et assurez-vous que l’émulateur de contrôleur de domaine principal et le maître RID sont toujours disponibles.

Les détenteurs de rôles de maître d’opérations sont attribués automatiquement lors de la création du premier contrôleur de domaine dans un domaine donné. Les deux rôles au niveau de la forêt (maître de schéma et maître d’affectation de noms de domaine) sont attribués au premier contrôleur de domaine créé dans une forêt. En outre, les trois rôles au niveau du domaine (maître RID, maître d’infrastructure et émulateur du contrôleur de domaine principal) sont attribués au premier contrôleur de domaine créé dans un domaine.

Ces attributions de rôle de maître d’opérations automatiques peuvent entraîner une utilisation très élevée du processeur sur le premier contrôleur de domaine créé dans la forêt ou le domaine. Pour éviter cela, attribuez (transférez) des rôles de maître d’opérations à différents contrôleurs de domaine dans votre forêt ou domaine. Placez les contrôleurs de domaine qui hébergent les rôles de maître d’opérations dans les zones où le réseau est fiable et où les maîtres d’opérations sont accessibles par tous les autres contrôleurs de domaine de la forêt.

Vous devez également désigner des maîtres d’opérations de secours (de remplacement) pour tous les rôles de maître d’opérations. Les maîtres d’opérations de secours sont des contrôleurs de domaine vers lesquels vous pouvez transférer les rôles de maître d’opérations en cas d’échec des détenteurs de rôles d’origine. Vérifiez que les maîtres d’opérations de secours sont des partenaires de réplication directe des maîtres d’opérations réels.

Planification de l’emplacement de l’émulateur du contrôleur de domaine principal

L’émulateur du contrôleur de domaine principal traite les modifications de mot de passe du client. Un seul contrôleur de domaine joue le rôle d’émulateur de contrôleur de domaine principal dans chaque domaine de la forêt.

Même si tous les contrôleurs de domaine sont mis à niveau vers Windows 2000, Windows Server 2003 et Windows Server 2008 et que le domaine fonctionne au niveau fonctionnel natif de Windows 2000, l’émulateur du contrôleur de domaine principal reçoit une réplication préférentiel des modifications de mot de passe effectuées par d’autres contrôleurs de domaine dans le domaine. Si un mot de passe a été récemment modifié, la réplication de cette modification sur chaque contrôleur de domaine du domaine prend du temps. Si l’authentification de connexion échoue sur un autre contrôleur de domaine en raison d’un mot de passe incorrect, ce contrôleur de domaine transfère la requête d’authentification à l’émulateur du contrôleur de domaine principal avant de décider d’accepter ou de rejeter la tentative d’ouverture de session.

Placez l’émulateur du contrôleur de domaine principal dans un emplacement qui contient un grand nombre d’utilisateurs de ce domaine pour les opérations de transfert de mot de passe si nécessaire. En outre, assurez-vous que l’emplacement est bien connecté à d’autres emplacements pour réduire la latence de réplication.

Pour obtenir une feuille de calcul qui vous aide à documenter les informations sur l'endroit où vous prévoyez de placer les émulateurs du contrôleur de domaine principal et le nombre d'utilisateurs pour chaque domaine représenté dans chaque emplacement, consultez Outils de déploiement pour Windows Server 2003, téléchargez Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip et ouvrez Emplacement du contrôleur de domaine (DSSTOPO_4.doc).

Vous devez vous reporter aux informations sur les emplacements dans lesquels vous devez placer des émulateurs du contrôleur de domaine principal lorsque vous déployez des domaines régionaux. Pour plus d’informations sur le déploiement de domaines régionaux, consultez Déploiement de domaines régionaux Windows Server 2008.

Configuration requise pour l’emplacement du maître d’infrastructure

Le maître d’infrastructure met à jour les noms des principaux de sécurité à partir d’autres domaines qui sont ajoutés aux groupes dans son propre domaine. Par exemple, si un utilisateur d’un domaine est membre d’un groupe dans un deuxième domaine et que le nom de l’utilisateur est modifié dans le premier domaine, le deuxième domaine n’est pas informé que le nom de l’utilisateur doit être mis à jour dans la liste des membres du groupe. Étant donné que les contrôleurs de domaine d’un domaine ne répliquent pas les principaux de sécurité sur les contrôleurs de domaine d’un autre domaine, le deuxième domaine ne prend jamais conscience de la modification en l’absence du maître d’infrastructure.

Le maître d’infrastructure surveille en permanence les appartenances aux groupes, en recherchant des principaux de sécurité à partir d’autres domaines. S’il en trouve un, il vérifie auprès du domaine du principal de sécurité que les informations sont mises à jour. Si les informations sont obsolètes, le maître d’infrastructure effectue la mise à jour, puis réplique la modification sur les autres contrôleurs de domaine de son domaine.

Deux exceptions s’appliquent à cette règle. Tout d’abord, si tous les contrôleurs de domaine sont des serveurs de catalogue global, le contrôleur de domaine qui héberge le rôle de maître d’infrastructure est insignifiant, car les catalogues globaux répliquent les informations mises à jour, quel que soit le domaine auquel elles appartiennent. Deuxièmement, si la forêt n’a qu’un seul domaine, le contrôleur de domaine qui héberge le rôle de maître d’infrastructure est insignifiant, car les principaux de sécurité d’autres domaines n’existent pas.

Ne placez pas le maître d’infrastructure sur un contrôleur de domaine qui est également un serveur de catalogue global. Si le maître d’infrastructure et le catalogue global se trouvent sur le même contrôleur de domaine, le maître d’infrastructure ne fonctionne pas. Le maître d’infrastructure ne trouvera jamais de données obsolètes ; par conséquent, il ne répliquera jamais les modifications apportées aux autres contrôleurs de domaine dans le domaine.

Emplacement du maître d’opérations pour les réseaux avec une connectivité limitée

N’oubliez pas que si votre environnement dispose d’un emplacement central ou d’un site hub dans lequel vous pouvez placer des détenteurs de rôles de maître d’opérations, certaines opérations de contrôleur de domaine qui dépendent de la disponibilité de ces détenteurs de rôles de maître d’opérations peuvent être affectées.

Par exemple, supposons qu’une organisation crée des sites A, B, C et D. Des liens de site existent entre A et B, entre B et C et entre C et D. La connectivité réseau reflète exactement la connectivité réseau des liens de sites. Dans cet exemple, tous les rôles de maître d’opérations sont placés dans le site A et l’option Ponter tous les liens de site n’est pas sélectionnée.

Bien que cette configuration aboutit à une réplication réussie entre tous les sites, les fonctions de rôle maître d’opérations présentent les limites suivantes :

• Les contrôleurs de domaine des sites C et D ne peuvent pas accéder à l’émulateur du contrôleur de domaine principal du site A pour mettre à jour un mot de passe ou pour le vérifier pour un mot de passe récemment mis à jour.
• Les contrôleurs de domaine des sites C et D ne peuvent pas accéder au maître RID du site A pour obtenir un pool RID initial après l’installation d’Active Directory et pour actualiser les pools RID à mesure qu’ils sont épuisés.
• Les contrôleurs de domaine des sites C et D ne peuvent pas ajouter ou supprimer des partitions de répertoire, DNS ou d’application personnalisées.
• Les contrôleurs de domaine dans les sites C et D ne peuvent pas apporter de modifications de schéma.

Pour obtenir une feuille de calcul pour vous aider à planifier l’emplacement du rôle de maître d’opérations, consultez Outils de déploiement pour Windows Server 2003, téléchargez Job_Aids_Designing_and_Deploying_Directory_and_Security_Services.zip et ouvrez Domain Controller Placement (DSSTOPO_4.doc).

Vous devrez vous référer à ces informations lorsque vous créez le domaine racine de forêt et les domaines régionaux. Pour plus d’informations sur le déploiement du domaine racine de forêt, consultez Déploiement d’un domaine racine de forêt Windows Server 2008. Pour plus d’informations sur le déploiement de domaines régionaux, consultez Déploiement de domaines régionaux Windows Server 2008.

Étapes suivantes

Vous trouverez des informations supplémentaires sur l’emplacement des rôles FSMO dans la rubrique de support Emplacement et optimisation FSMO sur les contrôleurs de domaine Active Directory.