- Rôles uniques au niveau de la Forêt
- Rôle
Le Maître de schéma ou d’opération gère l’ensemble des mises à jour et modifications du schéma.
Il assure également leur réplication sur l’ensemble des contrôleurs de domaines. Il ne peut y avoir qu’un seul Maître de schéma par forêt et seul le groupe « Administrateurs du schéma » peut y effectuer des modifications.
Résumé : Modifications et mises à jour du schéma + réplication des modifications dans tous les domaines de la forêt.
- Placement
Au niveau du domaine racine de la forêt, ce rôle doit être placé avec le Maître d’attribution des noms de domaine et également avec le PDC (recommandé).
- Impact en cas d’incident
En cas de panne ou d’incident impliquant ce rôle, le schéma ne pourra pas être étendu. Toutefois, l’impact sur la production sera minime, sauf si une mise à jour du schéma est prévue.
- Rôle
- Placement
- Impact en cas d’incident
Le Maître d’attribution de noms de domaine contrôle les ajouts et suppression de domaines dans la forêt. Il a également pour rôle la création et/ou suppression de relations avec les domaines externes.Notez qu’il ne peut y avoir qu’un seul Maître d’attribution de noms de domaine dans l’ensemble de la forêt.
Résumé : Ajout et suppression de domaines ou de partitions ‘Applications’ + création et suppression des relations entre les domaines + renommage de domaine (à partir de Windows Server 2003)
Au niveau du domaine racine de la forêt, ce rôle doit être placé avec le Maître de schéma et avec le PDC (recommandé). Si le contrôleur de domaine exécute Windows Server 2000, alors ce serveur devra également être GC. Dans le cas contraire, certaines opérations telles que la création de domaines grand-enfants échoueront. Enfin, si le contrôleur de domaine exécute Windows Server 2003 ou ultérieur, il ne devra en aucun cas être GC.
Si ce rôle n’est plus disponible, aucun ajout ou suppression de domaine (dcpromo) ne sera possible. Toutefois, l’impact restera minime même s’il est recommandé de disposer d’un serveur de secours avec une réplication directe de maître à partenaire.
- Rôles uniques au niveau du Domaine
- Rôle
- Placement
- Impact en cas d’incident
Le Maître RID est chargé d’attribuer à chaque objet Active Directory (utilisateur, groupe, ordinateur, …) un identifiant unique de sécurité (SID). Ce dernier est structuré de la façon suivante :
Un numéro de révision
Un identificateur de sécurité du domaine (domaine SID)
Un RID (Relative Identifier)
Parallèlement, et afin que différents contrôleurs de domaine n’assignent pas le même SID à deux objets différents, une plage RID est allouée à chaque DC. Lorsque cette plage est épuisée, une demande est effectuée auprès du RID afin de la renouveler. Notez qu’il ne peut y avoir qu’un seul Maître RID par domaine.
Résumé : Distribution des pools RID aux différents DC.
Le RID doit être placé de préférence avec le PDC. Si la charge sur le serveur le justifie, les rôles PDC et RID pourront être placés sur des DC différents, situés toutefois sur le même domaine et site Active Directory. De plus, ils devront être des partenaires de réplication directe. Pour des questions de
performances, il est recommandé ne pas le placer avec un GC.
Si ce rôle n’est plus disponible, les pools RID ne seront plus alloués au DC. Toutefois, il y a de fortes chances pour que les pools « RID » des DC ne soient pas totalement épuisés, sauf si la création de nombreux utilisateurs et postes est prévue.
- Rôle
- Placement
- Impact en cas d’incident
Le Maître d’infrastructure a pour rôle de maintenir à jour les références d’objet entre les différents domaines. Si un utilisateur d’un domaine A est ajouté dans un groupe d’un domaine B, il sera responsable de répliquer cette référence sur l’ensemble du domaine B. Il agit également comme « traducteur » parmi les identifiants globaux uniques (GUID), les identifiants de sécurité (SIDs) et les « distinguished names » (DNs). Par exemple, si vous listez les utilisateurs d’un groupe, vous pourrez parfois apercevoir des utilisateurs apparaissant avec leur SID (et non par leurs noms). Par ailleurs, si la corbeille Active Directory sous 2008 R2 est activée, ce rôle ne sera plus utilisé. Notez qu’il ne peut y avoir qu’un seul Maître d’infrastructure par domaine.
Résumé : Mise à jour des références d’objets entre les différents domaines + traduction des objets de type GUID, SID et DN en noms
En environnement multi-domaines, ce rôle ne doit pas être installé sur un serveur hébergeant le GC.
Toutefois, il existe deux exceptions à cette règle :
Forêt mono-domaine : il n’existe pas d’objets fantôme et de ce fait, ce rôle peut être placé avec un GC
Forêt multi-domaine où tous les DC sont GC : il n’y aura pas d’objets fantômes et ce rôle n’aura pas de « travail supplémentaire » à faire Notez qu’un objet de connexion direct vers un GC dans la forêt devra être créé (de préférence sur le même site).
Si ce rôle n’est plus disponible, l’appartenance et la traduction d’objets ne pourront plus être effectuées. Dans une forêt mono-domaine l’impact sera quasi-négligeable.
- Rôle
- Placement
- Impact en cas d’incident
Le rôle fondamental du PDC Emulator est de fournir une rétrocompatibilité avec les serveurs NT4.0 et les clients antérieurs à Windows 2000. Il est également chargé de la réplication des mots de passe et, de ce fait, est directement contacté en cas d’échec d’authentification afin de s’assurer que des
erreurs de réplication ne sont pas à l’origine du problème.
Le PDC agit également en tant que serveur de temps. Sous cet angle, il assure la synchronisation des horloges clientes avec les différents contrôleurs de domaine. Pour cela il utilise une relation hiérarchique qui contrôle l’autorité et interdit les boucles. Par défaut, les ordinateurs Windows
utilisent la hiérarchie suivante pour synchroniser leurs horloges :
Ordinateur clients : nomment le DC d’authentification comme partenaire de temps entrant
Serveur membres : mêmes processus que les ordinateurs clients
Contrôleurs de domaine d’un domaine : nomment le maître d’opérations du DC principal comme partenaire de temps entrant
PDC : utilisent la hiérarchie des domaines pour sélectionner leur partenaire de temps via le protocole SNTP
Le service de temps est également utilisé dans le cadre de l’authentification Kerberos qui nécessite un horodatage des paquets d’authentification. Autre point contrôlé par le PDC : les GPO. En effet, la console de gestion des stratégies de groupe « GPMC » utilise le DC hébergeant le rôle PDC comme DC par défaut pour toutes les opérations de création et de modification des GPO.
En définitive, il s’agit d’un rôle crucial ayant un réel impact sur les performances d’une infrastructure Active Directory.
Résumé :
Prise en charge des communications pour les serveurs NT4 et les clients antérieurs à 2000
Réplication des mots de passe utilisateur et ordinateur
Gestion des erreurs d’authentification et verrouillage des comptes
Serveur de temps et synchronisation avec les clients
Horodatage des paquets d’authentification Kerberos v5
Serveur de gestion par défaut pour les mises à jour des GPO
Ce rôle doit être placé de préférence avec le RID. Si la charge sur le serveur le justifie, les rôles PDC et RID pourront être placés sur des DC différents, situés toutefois sur le même domaine et site Active Directory. De plus, ils devront être des partenaires de réplication directe. Etant très sollicité et
nécessitant une forte montée en charge, il est recommandé de placer ce rôle sur le site disposant du plus grand nombre d’utilisateurs. De par sa criticité, il devra également être placé le plus proche possible des équipes techniques.
Enfin, il faut faire en sorte qu’il soit le moins sollicité par les clients. Pour cela il convient de réduire sa priorité et son poids dans les enregistrements DNS de type SRV. Cette action aura pour effet de favoriser l’authentification sur les autres DC.
Une défaillance de ce rôle peut entraîner :
L’impossibilité pour les serveurs NT4 et les clients antérieurs à 2000 de s’authentifier
Un arrêt de la réplication pour les domaines NT4
L’impossibilité de verrouiller les comptes utilisateurs
Une éventuelle perte de synchronisation entre les DC
Des problèmes d’authentification Kerberos
Des problèmes pour changer/appliquer les GPO