Combien de Maître d'Infrastructure pensez-vous avoir dans votre forêt ?

Bonjour à tous.

Je vous propose aujourd’hui un article sur un sujet que j’avais commencé sur mon blog précédent.

C’est un sujet purement Active Directory et qui n’a pas de lien avec la sécurité mais c’est une problématique qui peut être rencontrée dans beaucoup d’environnements Active Directory.

Je vais faire quelques petits rappels avant d’attaquer directement le sujet.

Les rôles FSMO en bref

Active Directory Domain Services définit cinq rôles de maître d'opérations:

• Maître de Schéma
• Maître de Nommage
• Maître RID
• Emulateur PDC 
• Maître d’Infrastructure

Chacun de ces maîtres d’opérations a un rôle bien spécifique dans un domaine et une forêt Active Directory :

• Le maître de schéma contrôle les mises à jour et les modifications apportées au schéma.
• Le maître de nommage contrôle l'ajout ou la suppression de domaines dans la forêt.
• Le maître RID alloue des séquences d'ID relatifs (RID) à chacun des différents contrôleurs de domaine de son domaine.
• L’Emulateur PDC traite les changements de mot de passe des clients et réplique ces changements à tous les contrôleurs de domaine de son domaine.
• Le maître d'infrastructure est responsable de la mise à jour des références des objets de son domaine à des objets dans d'autres domaines.

Les cinq rôles de maître d'opérations sont attribués automatiquement lorsque le premier contrôleur de domaine d’une forêt est créé. Deux rôles de forêt sont affectés au premier contrôleur de domaine créé dans une forêt, et trois rôles de domaine sont attribués au premier contrôleur de domaine créé dans un domaine.

Le maître de Schéma et le maître de Nommage sont des rôles d’une portée de forêt, ce qui signifie qu'il n'y a qu'un seul maître de schéma et un nom de domaine maître dans l'ensemble de la forêt.
Les autres maîtres d’opérations sont des rôles de portée de domaine, ce qui signifie que chaque domaine dans une forêt possède son propre Maître RID, son Emulateur PDC et son Maître d'Infrastructure.

Je ne vais pas rentrer plus dans le détails pour les rôles FSMO, si vous souhaitez plus d’informations je vous conseille de consulter les liens suivant:

• What are Operations Masters ?
• How Operations Masters Work ?

Donc, si je vous demande combien de maître d'infrastructure pensez-vous avoir dans votre forêt ?
Eh bien, votre réponse devrait être naturellement un pour chaque domaine puisque l’on a dit que chaque domaine dans une forêt possède un maître d’Infrastructure.
Évidemment, si je pose cette question c'est que peut-être pas la bonne réponse …

Avant d'aller plus loin, nous devons parler d’un autre sujet, les partitions Active Directory.

Les partitions Active Directory en bref

La base de données Active Directory est divisée de façon logique en partition d'annuaire.

On y retrouve les partitions suivantes :

• Partition de configuration
• Partition de schéma
• Partition de domaine

La partition de configuration contient les objets de configuration de la forêt. Les mises à jour de ce conteneur sont répliquées sur tous les contrôleurs de domaine de la forêt.

La partition de Schéma contient la définition des classes et attributs pour tous les types objets Active Directory existant dans la forêt. Les mises à jour de ce conteneur sont répliquées sur tous les contrôleurs de domaine de la forêt. 

La partition de domaine contient les utilisateurs, les ordinateurs, les groupes, et d’autres objets d’un domaine. Les mises à jour de la partition de domaine sont répliquées uniquement sur les contrôleurs de domaine du domaine et sur les serveurs de catalogue global si les attributs sont marqués pour être répliqués.

Windows Server 2003 a introduit un nouveau type de partition, les partitions d’application.

Une partition d'applications est une partition d'annuaire qui est répliquée uniquement sur les contrôleurs de domaine que l’on spécifie. Les partitions d'applications sont généralement créées par des applications qui les utilisent pour stocker et répliquer les données.

Les données peuvent être répliquées sur un contrôleur de domaine spécifique ou un ensemble de contrôleurs de domaine de la forêt. Les partitions d'applications peuvent contenir n'importe quel type d'objet, à l'exception des entités de sécurité.

Si votre DNS est intégré dans Active Directory, vous avez deux partitions d'application pour les zones DNS : ForestDNSZones et DomainDNSZones.

Pour plus d'informations sur les partitions Active Directory, vous pouvez consulter les liens suivant :

• Directory Partitions
• Application Directory Partitions

Peut-être vous demandez-vous pourquoi je vous parle des partitions d'annuaire Active Directory.

La réponse est simple, il y a un maître d'infrastructure pour chaque partition d'applications.

Donc, vous avez désormais la réponse à notre question,  il y a un maître d’Infrastructure pour chaque domaine et pour chaque partition d'applications.

Par exemple, si j'ai une forêt composée de 3 domaines avec du DNS intégré à Active Directory, j'aurais 7 Maîtres d'Infrastructure dans la forêt :

• 1 pour chaque domaine (3 domaines)
• 1 pour la partition d’applications ForestDNSZones (1 par forêt)
• 1 pour chaque partition d’applications DomainDNSZones (3 domaines)

Comment pouvons-nous le vérifier ?

J'ai construit le lab suivant, une Forêt composée de 3 domaines avec du DNS intégré à Active Directory :

• ROOT.ADDS  
• CHILD1.ROOT.ADDS  
• CHILD2.ROOT.ADDS

Nous allons d'abord voir comment on peut voir les partitions d'application.

C'est relativement facile avec Powershell:

Import-Module ActiveDirectory

Get-ADForest

On peut aussi utiliser la commande dsquery :

dsquery * "CN=CONFIGURATION,DC=ROOT,DC=ADDS" -filter "(systemflags=5)" -attr ncname

Nous avons désormais le contexte de nommage de nos 4 partitions d'application, mais cela ne suffit pas à trouver leur maître d'infrastructure.

Pour cela nous avons besoin de l'attribut suivant: ms-DS-NC-Replica-Location

Pour récupérer cet attribut, nous pouvons utiliser la commande suivante:

Get-ADObject -Filter {systemFlags -eq 5} -SearchBase ((Get-adforest).PartitionsContainer) -properties msDS-NC-Replica-Locations,ncname | fl

Nous avons désormais pour chaque partition d'application les contrôleurs de domaine qui ont un réplicat de la partition d'application.

Vous avez probablement remarqué que c'est un tableau composé des objets nTDSDSA de chaque contrôleur de domaine qui ont un réplicat de la partition d'application.

Avec cette information, nous ne pouvons pas récupérer le maître d'infrastructure de chaque partition d'application directement, mais avec l’objet nTDSDSA nous pouvons récupérer le nom DNS d’un contrôleur de domaine qui héberge un réplicat de la partition d’application puis rechercher les objets de classe infrastructureUpdate.

Voici le script qui permet d’afficher les maîtres d’Infrastructure de chaque partition d’application :

 Import-Module ActiveDirectory

Get-ADObject -Filter {systemFlags -eq 5} -SearchBase ((Get-adforest).PartitionsContainer) -properties msDS-NC-Replica-Locations,ncname|%{

$nTDSDSADN=$_.'msDS-NC-Replica-Locations'[0]

$Server=$nTDSDSADN.Replace("CN=NTDS Settings,","")

$DC = Get-adobject $Server -Properties dNSHostName

Get-ADObject -SearchBase $_.ncname -filter {objectclass -eq "infrastructureUpdate"} -properties objectclass,fsmoroleowner -server $DC.dNSHostName | select DistinguishedName, ObjectClass, FSMORoleOwner}|fl

On a désormais le contrôleur de domaine qui a le rôle de maître d’Infrastructure pour chacune des partitions d’applications.

Il faut maintenant se poser la question suivante, en quoi cette information est-elle importante ?

Lorsque vous faites un transfert de rôle (forcé ou non) du maître d’Infrastructure vous transférez le maître d’Infrastructure du contexte de nommage de votre domaine uniquement (Partition de Domaine), les maitres d’infrastructure des partitions d’application ne sont donc pas impactés.

Si vous avez fait des transferts forcés (Seize) de rôle et un metadata cleanup suite à un incident sur un contrôleur de domaine et que ce contrôleur de domaine hébergeait une partition d’application (DNS intégré AD par exemple), il est possible que le maître d’Infrastructure de la partition d’applications fasse encore référence à ce contrôleur de domaine.

J’ai rejoué ce scénario dans mon lab et voici le résultat :

On voit bien que l’attribut FSMORoleOwner  du maître d’Infrastructure fait toujours référence à l’ancien contrôleur de domaine qui a été supprimé.

Cette référence à un contrôleur de domaine supprimé peut générer différents incidents lors des promotions et dépromotions ou lors de l'exécution de commande adprep.

Si on regarde les contrôleurs de domaine hébergeant un réplicat des partitions d’application, il n’y a pas de référence à l’ancien contrôleur de domaine.

Il faut donc corriger uniquement l’attribut FSMORoleOwner de l’objet infrastructureUpdate.

Il existe une KB avec un script vbs permettant de corriger de ce problème : KB949257

Pour faire cette correction j'ai préféré utiliser Powershell :

$IM=Get-ADObject "CN=Infrastructure,DC=DomainDnsZones,DC=ROOT,DC=ADDS" -Properties FSMORoleOwner

$IM.FSMORoleOwner = (Get-ADDomainController -Identity ROOT-DC02).NTDSSettingsObjectDN

Set-ADObject -Instance $IM

On fait la correction pour la seconde partition d'applications:

$IM=Get-ADObject "CN=Infrastructure,DC=ForestDnsZones,DC=ROOT,DC=ADDS" -Properties FSMORoleOwner

$IM.FSMORoleOwner = (Get-ADDomainController -Identity ROOT-DC02).NTDSSettingsObjectDN

Set-ADObject -Instance $IM

On peut vérifier ensuite que la correction a bien été effectuée.

Il faut donc vérifier les maîtres d'Infrastructure de vos partitions d'application lorsque vous effectuez un metadata cleanup d'un contrôleur de domaine.

Il faut aussi intégrer cette vérification dans votre procédure de Disaster Recovery Active Directory.

J'espère que cet article vous a intéressé et que vous avez appris quelque chose, il ne vous reste plus qu'à vérifier si vous n'avez pas cette problématique dans votre environnement sans le savoir.