Sites et sous-réseaux AD : vérifier la sélection du DC

Sites et sous-réseaux AD : que vérifier avant de modifier la topologie

Un examen des sites et sous-réseaux AD doit répondre à une question pratique : un client représentatif identifie-t-il le site Active Directory prévu et découvre-t-il un contrôleur de domaine approprié ? Un site sans objet serveur collecté et un site sans objet sous-réseau associé sont des points de départ utiles pour une investigation. Aucun de ces résultats ne démontre à lui seul une attaque ni ne détermine la modification de configuration justifiée.

Ce guide a été vérifié à partir de Microsoft Learn et de l’implémentation d’etc-collector le 3 octobre 2026. Les commandes ci-dessous sont des exemples documentés d’inspection et de configuration ; elles n’ont pas été exécutées sur un domaine client. Utilisez votre inventaire réseau, les résultats de l’annuaire et les observations des clients pour établir la cause avant de modifier une association.

Une agence peut volontairement ne disposer d’aucun DC local. À l’inverse, un site peut posséder un objet sous-réseau alors que d’autres réseaux réels de clients restent non déclarés. Distinguez ces situations : compter des objets d’annuaire ne teste ni la couverture réseau ni la réussite de l’authentification.

Comment l’association au site influe sur la sélection du DC et la réplication

La documentation Microsoft sur DC locator décrit la découverte par Netlogon, les annonces DNS et les réponses LDAP UDP. Pendant la négociation, un DC identifie le site du client à partir de son sous-réseau IP. Si le premier DC se trouve hors du site approprié, les informations de site client renvoyées peuvent déclencher une nouvelle recherche propre à ce site. La découverte utilise également des informations en cache ; un DC renvoyé isolément décrit cette requête, pas l’historique complet de l’authentification des applications.

Un sous-réseau client sans association laisse la sélection du site incomplète et peut conduire à un DC hors de l’emplacement prévu. Cela justifie d’examiner l’adresse réelle du client et son association, plutôt que de supposer que chaque client choisit un DC au hasard. Un DC distant peut aussi être le service prévu pour une agence qui n’en possède pas localement.

Les concepts de réplication de Microsoft distinguent les objets sous-réseaux, qui associent les adresses réseau aux sites, des liens de sites et des objets de connexion utilisés pour la réplication. L’objet serveur d’un DC possède un objet enfant NTDS Settings représentant le DC qui participe à la réplication. Le KCC construit les connexions de réplication ; les liens de sites décrivent les chemins logiques et les coûts de réplication.

Pour cet examen, gardez deux questions distinctes. La découverte côté client détermine quel DC une machine peut localiser depuis son réseau actuel. La conception de la réplication détermine comment les DC échangent les modifications de l’annuaire. Une association correcte entre client et site ne prouve pas la bonne santé de la réplication, et une réplication réussie ne prouve pas que chaque réseau client possède l’association au site prévue.

Le guide de sécurité des zones DNS AD traite des transferts, des mises à jour dynamiques et des permissions des enregistrements. Ces contrôles sur les données de résolution complètent l’investigation, mais ne définissent pas l’association entre sous-réseau et site. Examinez le DNS lorsque la découverte échoue, tout en distinguant les preuves relatives à la topologie.

Détection : rapprocher l’inventaire de l’annuaire des observations des clients

1. Établir ce que les requêtes d’annuaire ont réellement renvoyé

Utilisez un poste d’administration équipé du module PowerShell ActiveDirectory et un compte autorisé à lire les objets de configuration concernés. Les références Microsoft documentent Get-ADReplicationSubnet et Get-ADReplicationSite. Les exemples suivants, en lecture seule, demandent les objets et leurs propriétés :

Get-ADReplicationSubnet -Filter * -Properties *
Get-ADReplicationSite -Filter * -Properties *

Consignez le serveur d’annuaire interrogé, le contexte du compte, la réussite de la requête et l’heure de collecte avec les résultats. Examinez les noms des sous-réseaux et leurs associations Site, puis comparez le site associé au nom distinctif du site. Ne transformez pas une erreur d’accès ou un export incomplet en conclusion que les objets n’existent pas.

Rapprochez cet export de l’inventaire actuel de l’équipe réseau : réseaux d’agences, réseaux de bureaux, plages des clients VPN et autres réseaux depuis lesquels les clients du domaine se connectent réellement. Pour chaque plage pertinente, identifiez le site attendu et le responsable capable de le confirmer. Cette comparaison est une étape de revue manuelle ; les deux contrôles EtcSec ci-dessous ne l’effectuent pas.

Commencez par un petit ensemble représentatif de clients incluant les réseaux concernés par le constat. Consignez l’adresse active et le contexte de connexion pour chaque observation. Un ordinateur portable testé au bureau et ce même portable testé via un VPN correspondent à deux observations réseau différentes. Conservez le site attendu et la raison de cette attente avant de comparer la sortie des commandes.

2. Observer l’appartenance au site et le résultat de DC locator

La page Microsoft de dépannage de la synchronisation d’annuaire documente ces commandes pour vérifier l’appartenance d’un ordinateur à un site et localiser un DC. Remplacez le domaine d’exemple par votre véritable domaine DNS :

nltest /dsgetsite
nltest /dsgetdc:contoso.com

Lisez le site obtenu, le DC sélectionné et les champs Our Site Name et DC Site Name lorsqu’ils sont renvoyés. Conservez les échecs en tant qu’échecs, y compris leur texte d’erreur. Un résultat de site indisponible nécessite une investigation ; il ne prouve pas que le client appartient au bureau géographiquement le plus proche.

Pour comparer délibérément une nouvelle découverte, la référence Nltest documente /force comme moyen d’éviter les informations de découverte en cache :

nltest /dsgetdc:contoso.com /force

Conservez les deux résultats au lieu d’écraser la première observation. Comparez le site client indiqué à l’association attendue, et le site du DC à la conception documentée de l’agence. S’ils diffèrent, examinez l’association, la découverte et l’exception WAN prévue avant toute modification. Ces commandes sollicitent la découverte ; validez séparément le comportement de l’application concernée si une plainte d’authentification a déclenché l’examen.

3. Corréler les indices de clients sans association

Microsoft documente l’événement NETLOGON 5807 dans Réponse retardée du DC aux requêtes LDAP ou Kerberos. L’événement décrit des connexions provenant d’adresses de clients qui ne correspondent à aucun site existant. Cette page indique %SystemRoot%\debug\netlogon.log et son fichier de rotation .bak comme emplacements des noms et adresses des clients, les entrées pertinentes étant identifiées par NO_CLIENT_SITE:.

Lorsque cet événement ou les entrées de journal associées sont présents, rapprochez les adresses observées de l’inventaire réseau et des sous-réseaux déclarés. Vérifiez quelle connexion a produit l’adresse avant de l’affecter à un site. L’absence de cet événement ne remplace pas la comparaison avec l’inventaire, et sa présence n’identifie pas un attaquant.

Remédiation : corriger l’association ou documenter l’exception prévue (Remediation)

1. Lever d’abord les incertitudes sur l’inventaire

Avant de modifier la topologie, rapprochez l’instantané du collecteur de lectures réussies de l’annuaire. Si l’énumération des serveurs ou des sous-réseaux a échoué, examinez le contexte de collecte et répétez l’inventaire. Ne déployez pas un DC, ne supprimez pas un site et n’inventez pas un sous-réseau dans le seul but d’effacer une absence apparente produite par une requête en échec.

Pour un site sans DC local, demandez aux responsables du domaine et du réseau si cette situation est volontaire. Documentez l’emplacement du DC qui assure le service, la dépendance WAN attendue, le responsable et le déclencheur de réexamen. Conservez cette exception avec les observations des clients afin qu’un autre réviseur comprenne pourquoi la découverte intersite est acceptable à cet endroit.

2. Corriger une association absente ou erronée confirmée

Identifiez le véritable réseau client et le site existant qui doit le représenter. Examinez l’association proposée avec le responsable réseau, y compris les autres réseaux susceptibles d’être affectés. Une définition de sous-réseau doit exprimer la conception réseau convenue, pas simplement recopier l’adresse de la première machine qui a produit une erreur.

Pour un sous-réseau réellement manquant, Microsoft documente cet exemple de création dans New-ADReplicationSubnet :

New-ADReplicationSubnet -Name "10.10.0.0/22" -Site Asia -Location "Tokyo,Japan"

Il s’agit du réseau et du site illustratifs de Microsoft, pas d’une configuration proposée pour votre environnement. Substituez un réseau vérifié et un site existant prévu uniquement après avoir confirmé que l’objet sous-réseau manque réellement. Pour un objet existant associé au mauvais site, corrigez son association Site dans Active Directory Sites and Services selon votre processus habituel de changement. Conservez les valeurs initiales et leur remplacement approuvé dans le dossier de changement.

Si un serveur est réellement retiré du service, suivez les recommandations distinctes sur l’hygiène des objets DC et le nettoyage des métadonnées. Confirmez son retrait avant le nettoyage. Une liste vide de serveurs collectés ne prouve pas qu’un DC en activité doit être supprimé, et ajouter ou supprimer des objets serveur ne remplace pas la correction de l’association des sous-réseaux clients.

3. Revérifier les clients représentatifs et conserver les preuves

Répétez l’inventaire de l’annuaire et les commandes de découverte côté client une fois le changement visible sur le serveur d’annuaire utilisé pour la validation. Testez les mêmes réseaux représentatifs, y compris les cas prévus de service distant. Consignez le site attendu, le site observé, le DC renvoyé et l’exception restante pour chaque client.

Revérifiez le parcours applicatif qui a motivé l’investigation et examinez séparément la réplication si la topologie a changé. La disparition d’un constat d’inventaire confirme utilement les objets collectés, mais ne prouve pas que chaque réseau ou chaque application utilise désormais le chemin voulu.

Comment EtcSec détecte ces situations

L’implémentation etc-collector d’EtcSec évalue deux contrôles Network à partir de l’inventaire collecté des sites et sous-réseaux :

• SITE_TOPOLOGY_ISSUES — Low. site-topology.go:23 parcourt data.Sites et retient chaque site dont len(site.Servers) == 0. Il renvoie un constat dont Count correspond au nombre de ces sites, avec leurs noms dans sitesWithoutDc. Lorsque le nombre est positif, il ajoute les entités des sites concernés. Il renvoie également le constat lorsque le nombre vaut zéro ; cette branche ne comporte aucune condition de latence mesurée.
• SUBNET_MISSING — Info. subnet-missing.go:24 recherche dans les sous-réseaux collectés un Subnet.SiteDN correspondant à chaque Site.DistinguishedName au moyen de strings.EqualFold. Un site sans correspondance contribue à Count et à sitesWithoutSubnets ; les détails comprennent également les nombres totaux de sites et de sous-réseaux. Les entités des sites concernés ne sont ajoutées que si IncludeDetails est activé et que le nombre est positif. Un seul sous-réseau associé satisfait ce prédicat même si d’autres réseaux réels restent sans association.

Le fournisseur LDAP compte dans l’interprétation. Dans client.go:1872, GetSitesAndSubnets recherche dans le conteneur Servers de chaque site avec (objectClass=server). Bien que son commentaire mentionne nTDSDSA, le code ne vérifie pas la présence d’un enfant NTDS Settings et ne teste pas la santé du DC. Il ajoute le dNSHostName d’un serveur, avec repli sur name, uniquement lorsqu’une valeur non vide est disponible.

L’échec d’une requête de sites renvoie une erreur. L’échec d’une requête de serveurs propre à un site est ignoré et peut laisser Servers vide. L’échec d’une requête de sous-réseaux renvoie sites, nil, nil, sans erreur. Ces dernières branches peuvent simuler une absence dans les données transmises aux détecteurs. Une liste de sites ou de sous-réseaux apparemment vide exige donc des preuves d’inventaire indépendantes et issues de lectures réussies.

Aucun des deux contrôles n’analyse la couverture CIDR, ne valide les adresses IP des clients, ne mesure la latence, n’évalue les coûts des liens de sites ou les connexions de réplication, ni ne teste l’accessibilité des DC. Aucun ne prouve que chaque serveur déclaré est un DC sain. Un site volontairement dépourvu de DC peut produire le constat Low, tandis qu’un site possédant un sous-réseau peut éviter le décompte Info malgré des lacunes ailleurs.