Inventaire des contrôleurs de domaine AD : rapprocher les métadonnées FSMO

Ce qu’établit un inventaire des contrôleurs de domaine AD

Un inventaire des contrôleurs de domaine AD doit identifier les DC du périmètre et expliquer l’origine de chaque entrée. Les noms, systèmes d’exploitation, sites, indicateurs de lecture seule, rôles FSMO et partenaires de réplication configurés aident l’opérateur à comprendre l’annuaire. Ils ne prouvent pas, à eux seuls, qu’un DC est joignable, que tous les DC attendus ont été collectés ou que les modifications de l’annuaire se répliquent correctement.

La vérification pratique consiste à rapprocher l’instantané du collecteur de lectures indépendantes de l’annuaire, en conservant le domaine, le serveur interrogé, les contextes de nommage et les erreurs de collecte. Une liste FSMO vide doit rester distincte d’une lecture réussie montrant que le DC concerné ne détient aucun rôle. De même, un partenaire configuré renseigne sur la topologie ; il ne constitue pas un résultat de réplication réussi.

Ce guide a été vérifié à partir de Microsoft Learn et du code source d’etc-collector le 4 octobre 2026. Les commandes sont des exemples documentés d’inspection en lecture seule ou des adaptations de syntaxes documentées. Elles n’ont pas été exécutées sur l’annuaire d’un client. La procédure ci-dessous propose une revue des preuves, et ne rapporte pas un incident observé.

Comment le périmètre et les métadonnées facultatives influencent le résultat

Commencez par le relevé de collecte plutôt que par le seul affichage. Identifiez le domaine demandé, le point de terminaison LDAP, le BaseDN, le contexte du compte, l’heure de collecte et les exclusions. Conservez les contextes de nommage réellement impliqués dans les lectures, y compris le contexte de configuration utilisé pour l’enrichissement. Une étiquette de domaine sans serveur ni contexte de recherche ne suffit pas à expliquer pourquoi deux exports diffèrent.

Dans le collecteur inspecté, les DC sont dérivés des objets ordinateur collectés après application des exclusions. Le fournisseur de métadonnées enrichit cette liste fournie. Un partenaire qui ne peut pas être rattaché à cette liste de DC peut donc être omis du champ des partenaires obtenu. Un tableau vide peut ainsi refléter un rapprochement incomplet plutôt qu’une absence d’objets de connexion.

Le fournisseur construit également sa base de recherche de configuration en préfixant le BaseDN avec CN=Configuration,. Lors de la revue d’une collecte sur un domaine enfant, comparez ce contexte construit au contexte de configuration réel de la forêt utilisé dans votre inspection indépendante de l’annuaire. L’éventuelle discordance de périmètre est une déduction statique tirée du code, et non un échec reproduit dans la forêt d’un client. Conservez le contexte et le résultat de recherche avant de décider s’ils expliquent un champ manquant.

Un relevé de revue utile associe chaque identifiant de DC à sa source et à un état de lecture explicite. Les états proposés sont lecture réussie, non collecté, échec de lecture et pas encore vérifié. Ce sont des libellés de procédure, pas des valeurs émises par le détecteur. Ne convertissez pas silencieusement les trois derniers états en liste vide ou en indicateur faux.

Détection : rapprocher indépendamment les DC et les détenteurs FSMO

1. Énumérer le domaine prévu

Utilisez un hôte d’administration disposant du module PowerShell ActiveDirectory et un compte autorisé à lire les données pertinentes de l’annuaire. La référence Get-ADDomainController de Microsoft documente le jeu de paramètres Filter et -Server. L’adaptation suivante demande les DC à un serveur d’annuaire nommé explicitement ; remplacez le nom d’hôte illustratif par le serveur vérifié pour votre domaine :

Get-ADDomainController -Filter * -Server "dc01.contoso.com"

Consignez le serveur effectivement interrogé avec les objets renvoyés et les erreurs. Comparez les identifiants et l’appartenance au domaine avec les entrées du collecteur avant d’examiner les différences d’enrichissement. Conservez les objets absents de l’un ou l’autre export comme écarts à examiner, y compris toute exclusion connue expliquant une différence.

La référence distingue la récupération par Filter ou Identity de la découverte. Un appel de découverte trouve un DC qui satisfait ses critères ; il n’énumère pas tous les DC. Pour une revue à l’échelle de la forêt, conservez des résultats distincts par domaine. La référence Get-ADForest inclut une énumération à travers la collection Domains de la forêt. Ne présentez pas un export réussi d’un seul domaine comme une couverture complète de la forêt.

2. Lire les rôles de chaque DC, puis recouper les détenteurs du domaine et de la forêt

La page de gestion des rôles FSMO de Microsoft fournit cet exemple exact d’inspection du domaine courant :

$domainControllers = Get-ADDomainController -Filter *
foreach ($dc in $domainControllers) {
    Write-Output "Name: $($dc.Name)"
    Write-Output "OperationMasterRoles:"
    foreach ($role in $dc.OperationMasterRoles) {
        Write-Output "- $role"
    }
}

Cet exemple utilisant le contexte de connexion par défaut, consignez-le explicitement. Privilégiez l’énumération précédente avec serveur explicite pour préparer une comparaison maîtrisée. Conservez les objets DC complets renvoyés ainsi que le résumé des rôles, pour qu’un choix de mise en forme ne puisse pas masquer l’identité source.

La documentation Get-ADDomain expose PDCEmulator, RIDMaster et InfrastructureMaster. La sortie de Get-ADForest expose SchemaMaster et DomainNamingMaster. Ces adaptations en lecture seule utilisent leurs paramètres Identity et Server documentés :

Get-ADDomain -Identity "contoso.com" -Server "dc01.contoso.com"
Get-ADForest -Identity "contoso.com" -Server "dc01.contoso.com"

Remplacez indépendamment le domaine et la forêt prévus ; ils n’ont pas nécessairement le même nom DNS. Enregistrez la sortie complète, y compris l’identité du domaine renvoyée et son appartenance à la forêt. Comparez chaque détenteur aux propriétés de rôle de chaque DC et aux métadonnées du collecteur. Un détenteur de rôle de forêt hors du périmètre d’une collecte de domaine enfant soulève une question de périmètre ; ce n’est pas la preuve d’un rôle manquant.

3. Conserver les désaccords et les données non lues

Pour chaque écart, joignez les deux sorties, leurs heures de collecte, les identités des serveurs et les résultats de lecture. Une lecture indépendante réussie identifiant un autre détenteur peut expliquer pourquoi un DC n’a aucun rôle. Une lecture échouée ne le peut pas. Si des lectures avec serveur explicite divergent, conservez les deux au lieu de choisir celle qui donne à l’inventaire une apparence d’exhaustivité.

Désignez un responsable pour examiner le contexte de collecte et toute incohérence de l’annuaire. La question immédiate concernant les preuves est de savoir si la valeur manquante reflète le périmètre, une exclusion, des métadonnées non lues ou un état vérifié de l’annuaire. Répondez à cette question avant de planifier une modification d’AD.

Corriger les preuves avant de modifier l’annuaire (Remediation)

1. Résoudre les lacunes de collecte et répéter la comparaison

Examinez le point de terminaison consigné, le BaseDN du domaine, le contexte de configuration, les exclusions et les permissions avec le responsable de l’annuaire. Corrigez un problème confirmé de contexte de collecte en suivant la procédure de configuration prise en charge par le collecteur. Conservez ensemble l’instantané initial, le motif de la correction et les nouveaux résultats de lecture.

Répétez l’énumération des DC dans le périmètre et les commandes d’inspection du domaine et de la forêt ci-dessus. Comparez de nouveau les mêmes identifiants et propriétés de rôle. Si des métadonnées restent non lues, rendez cet état visible et attribuez l’enquête non résolue ; remplir manuellement le champ du rapport détruirait la distinction entre une lecture de l’annuaire et une supposition de l’opérateur.

Un relevé d’acceptation doit indiquer quel domaine a été rapproché, quels DC restent inexpliqués, quels détenteurs de rôle ont été lus indépendamment et quels champs restent inconnus. Traitez un DC exclu comme exclu, au lieu de le signaler comme absent de l’annuaire. Répéter une collecte avec succès apporte une preuve utile, mais n’étend pas son périmètre au-delà des domaines et contextes réellement interrogés.

2. Vérifier la réplication comme un contrôle distinct

Le guide de dépannage de la réplication de Microsoft documente cette commande exacte à exécuter dans une invite de commandes avec élévation :

repadmin /showrepl * /csv > showrepl.csv

La procédure documentée exige l’appartenance au groupe Enterprise Admins ou des droits équivalents. Suivez la procédure de diagnostic autorisée de l’organisation. Conservez le CSV et les erreurs de commande. Examinez les partenaires sources, les contextes de nommage, les informations de dernière réussite et les échecs séparément de la liste des partenaires configurés de l’inventaire.

Le même guide identifie le journal d’événements Directory Service et la sortie de Repadmin comme preuves de dépannage. Utilisez le texte réel de l’erreur pour examiner un résultat de diagnostic échoué. Une connexion répertoriée dans un inventaire ne répond pas à ces questions de santé, et une cible de diagnostic injoignable reste non résolue même si d’autres DC ont renvoyé une sortie.

Consignez le périmètre et le résultat du contrôle de réplication dans son propre relevé de preuves. Ne remplacez pas le champ des partenaires configurés par un verdict de santé et ne qualifiez pas toutes les connexions de saines parce qu’une requête a réussi. Cet article sur l’inventaire ne prescrit ni changement de topologie ni opération de récupération à partir d’une lacune de métadonnées.

3. Relier un inventaire qualifié à la planification de la topologie et de la récupération

Utilisez les informations de site vérifiées avec la sélection du DC par les clients et la correspondance entre sous-réseaux et sites. Cette revue rapproche la topologie de l’annuaire des réseaux clients réels et des observations de découverte. Un nom de site inventorié ne prouve à lui seul ni une sélection appropriée par les clients ni la santé de la réplication.

Fournissez le relevé rapproché des DC et détenteurs de rôle comme entrée de la planification de la récupération de forêt et de la validation des sauvegardes. La préparation à la récupération exige des DC et des rôles connus, mais aussi une sélection des sauvegardes, des preuves de restauration et une procédure propre à l’environnement. Un export d’inventaire ne valide pas une restauration et n’établit pas que l’état récupéré de l’annuaire est digne de confiance.

Comment EtcSec détecte cela

L’etc-collector d’EtcSec émet INFO_DOMAIN_CONTROLLER comme constat d’inventaire. L’implémentation inspectée de dc-inventory.go produit un constat Info avec Count 1 par DC collecté. Elle ne renvoie aucun constat lorsque la liste de DC fournie est vide. Ce comportement ne constitue pas un verdict de vulnérabilité et ne prouve pas qu’un annuaire sans entrée renvoyée ne contient aucun DC.

Les entités affectées détaillées ne sont jointes qu’avec IncludeDetails. Elles contiennent les champs de base d’identité de l’ordinateur et de système d’exploitation, avec des rôles FSMO, un état RODC, un site et des partenaires de réplication facultatifs. Un enrichissement manquant laisse des tableaux vides ou des valeurs par défaut. Les consommateurs doivent qualifier ces valeurs avant de les traiter comme des observations négatives issues de lectures réussies.

La méthode GetDCMetadata du fournisseur LDAP lit les objets détenteurs de rôle et la configuration NTDS/de connexion. Les erreurs de recherche FSMO ou les résultats vides sont ignorés. Une erreur de recherche NTDS laisse les champs de site et de partenaires non renseignés, tandis que l’indicateur RODC et les rôles déjà lus restent disponibles ; les erreurs de recherche de connexions sont ignorées. Les identifiants des partenaires sont rapprochés de la liste de DC fournie. Le moteur n’affecte également DCInfo que si l’appel de métadonnées réussit.

Il s’agit de limites observées dans le code source au commit afca1b9f7bba6f076d6a6493371486071001452b, et non d’échecs reproduits chez des clients. Le contrôle ne teste pas la santé de la réplication, ne mesure aucun échange réussi de modifications et ne décide pas de l’aptitude à la récupération. Utilisez-le pour faire apparaître les actifs DC collectés, puis qualifiez la couverture et les métadonnées facultatives avec les lectures indépendantes décrites ci-dessus.