AD-Standorte: Subnetze und DC-Auswahl prüfen

AD-Standorte: Subnetze vor einer Topologieänderung prüfen

AD-Standorte und Subnetze zu prüfen bedeutet, eine praktische Frage zu beantworten: Erkennt ein repräsentativer Client den vorgesehenen Active Directory-Standort und findet er einen geeigneten Domänencontroller? Ein Standort ohne erfasste Serverobjekte und ein Standort ohne zugeordnete Subnetzobjekte sind hilfreiche Anlässe für eine Untersuchung. Keines dieser Ergebnisse belegt für sich allein einen Angriff oder zeigt, welche Konfigurationsänderung gerechtfertigt ist.

Dieser Leitfaden wurde am 3. Oktober 2026 mit Microsoft Learn und der Implementierung von etc-collector abgeglichen. Die folgenden Befehle sind dokumentierte Beispiele für Prüfung und Konfiguration; sie wurden nicht in einer Kundendomäne ausgeführt. Ermitteln Sie die Ursache anhand Ihres Netzwerkinventars, der Verzeichnisabfragen und der Client-Beobachtungen, bevor Sie eine Zuordnung ändern.

Eine Niederlassung kann bewusst ohne lokalen DC betrieben werden. Umgekehrt kann ein Standort ein Subnetzobjekt haben, während weitere tatsächlich genutzte Client-Netze nicht deklariert sind. Halten Sie diese Fälle auseinander: Die Anzahl von Verzeichnisobjekten prüft weder die Netzabdeckung noch den Erfolg der Authentifizierung.

Wie Standortzuordnungen die DC-Auswahl und Replikation beeinflussen

Microsofts Dokumentation zu DC locator beschreibt die Suche über Netlogon, DNS-Ankündigungen und LDAP-UDP-Antworten. Während der Aushandlung ermittelt ein DC den Standort des Clients anhand dessen IP-Subnetzes. Liegt der erste DC außerhalb des passenden Standorts, können die zurückgegebenen Informationen zum Client-Standort eine weitere, standortspezifische Suche auslösen. Die Suche verwendet auch zwischengespeicherte Informationen; ein einzelner zurückgegebener DC ist eine Beobachtung dieser Anfrage, keine vollständige Historie der Anwendungsauthentifizierung.

Bei einem nicht zugeordneten Client-Subnetz bleibt die Standortauswahl unvollständig, was zu einem DC außerhalb des vorgesehenen Standorts führen kann. Das ist ein Anlass, die tatsächliche Client-Adresse und die Zuordnung zu untersuchen, statt anzunehmen, dass jeder Client seinen DC zufällig auswählt. Ein entfernter DC kann auch die vorgesehene Versorgung einer Niederlassung ohne lokalen DC sein.

Microsofts Replikationskonzepte unterscheiden Subnetzobjekte, die Netzwerkadressen Standorten zuordnen, von Standortverknüpfungen und Verbindungsobjekten für die Replikation. Das Serverobjekt eines DC hat ein untergeordnetes NTDS Settings-Objekt, das den replizierenden DC repräsentiert. Der KCC erstellt Replikationsverbindungen; Standortverknüpfungen beschreiben logische Replikationspfade und deren Kosten.

Behalten Sie bei dieser Prüfung zwei getrennte Fragen bei. Die Client-Suche fragt, welchen DC ein Rechner aus seinem aktuellen Netz finden kann. Das Replikationsdesign fragt, wie DCs Verzeichnisänderungen austauschen. Eine korrekte Zuordnung des Clients zu einem Standort belegt keinen gesunden Replikationszustand, und erfolgreiche Replikation belegt nicht, dass jedes Client-Netz dem vorgesehenen Standort zugeordnet ist.

Der Leitfaden zur Sicherheit von AD-DNS-Zonen behandelt Zonentransfers, dynamische Updates und Berechtigungen für Einträge. Diese Kontrollen der Namensauflösungsdaten ergänzen die Untersuchung, definieren aber nicht die Zuordnung von Subnetzen zu Standorten. Untersuchen Sie DNS, wenn die Suche scheitert, und halten Sie die Nachweise zur Topologie davon getrennt.

Erkennung: Verzeichnisinventar mit Client-Beobachtungen abgleichen

1. Feststellen, was die Verzeichnisabfragen tatsächlich zurückgegeben haben

Verwenden Sie einen Verwaltungsrechner mit dem ActiveDirectory PowerShell-Modul und ein Konto, das die relevanten Konfigurationsobjekte lesen darf. Microsoft dokumentiert Get-ADReplicationSubnet und Get-ADReplicationSite. Die folgenden Beispiele führen ausschließlich Lesezugriffe aus und fragen die Objekte samt Eigenschaften ab:

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

Halten Sie den abgefragten Verzeichnisserver, den Kontokontext, den Erfolg der Abfrage und den Erfassungszeitpunkt zusammen mit den Ergebnissen fest. Prüfen Sie die Subnetznamen und ihre Site-Zuordnungen und vergleichen Sie den zugeordneten Standort mit dessen Distinguished Name. Leiten Sie aus einem Zugriffsfehler oder einem unvollständigen Export nicht ab, dass die Objekte nicht existieren.

Gleichen Sie diesen Export mit dem aktuellen Inventar des Netzwerkteams ab: Niederlassungsnetze, Büronetze, VPN-Client-Adressbereiche und andere Netze, aus denen Domänenclients tatsächlich Verbindungen aufbauen. Ermitteln Sie für jeden relevanten Bereich den erwarteten Standort und die verantwortliche Person, die ihn bestätigen kann. Dieser Vergleich ist ein manueller Prüfschritt; die beiden unten beschriebenen EtcSec-Prüfungen führen ihn nicht durch.

Beginnen Sie mit einer kleinen, repräsentativen Gruppe von Clients, die auch die Netze hinter dem Befund umfasst. Erfassen Sie für jede Beobachtung die aktive Adresse und den Verbindungskontext. Ein im Büro getestetes Notebook und dasselbe über VPN getestete Notebook sind unterschiedliche Netzwerkbeobachtungen. Halten Sie den erwarteten Standort und die Begründung dafür fest, bevor Sie die Befehlsausgabe vergleichen.

2. Standortzugehörigkeit und Ergebnis von DC locator beobachten

Microsofts Seite zur Fehlerbehebung bei der Verzeichnissynchronisierung dokumentiert diese Befehle zur Prüfung der Standortzugehörigkeit eines Computers und zur Suche nach einem DC. Ersetzen Sie die Beispieldomäne durch Ihre tatsächliche DNS-Domäne:

nltest /dsgetsite
nltest /dsgetdc:contoso.com

Lesen Sie das Standortergebnis, den ausgewählten DC sowie die Felder Our Site Name und DC Site Name, sofern sie zurückgegeben werden. Bewahren Sie Fehlschläge als solche auf, einschließlich des Fehlertexts. Ein nicht verfügbares Standortergebnis muss untersucht werden; es belegt nicht, dass der Client geografisch dem nächstgelegenen Büro zuzuordnen ist.

Für einen gezielten Vergleich mit einer erneuten Suche dokumentiert die Nltest-Referenz /force als Möglichkeit, die zwischengespeicherten Suchinformationen zu umgehen:

nltest /dsgetdc:contoso.com /force

Behalten Sie beide Ergebnisse, statt die erste Beobachtung zu überschreiben. Vergleichen Sie den gemeldeten Client-Standort mit der erwarteten Zuordnung und den DC-Standort mit dem dokumentierten Niederlassungsdesign. Bei Abweichungen untersuchen Sie Zuordnung, Suche und die beabsichtigte WAN-Ausnahme, bevor Sie etwas ändern. Diese Befehle prüfen die Suche; validieren Sie das Verhalten der betroffenen Anwendung separat, wenn eine Authentifizierungsbeschwerde Anlass der Prüfung war.

3. Nachweise für nicht zugeordnete Clients korrelieren

Microsoft dokumentiert NETLOGON-Ereignis 5807 unter Verzögerte DC-Antwort auf LDAP- oder Kerberos-Anfragen. Das Ereignis beschreibt Verbindungen von Client-Adressen, die keinen vorhandenen Standorten zugeordnet sind. Die Seite nennt %SystemRoot%\debug\netlogon.log und dessen rotierte .bak-Datei als Speicherorte für Client-Namen und -Adressen; NO_CLIENT_SITE: kennzeichnet die relevanten Einträge.

Wenn dieses Ereignis oder die zugehörigen Logeinträge vorhanden sind, gleichen Sie die beobachteten Adressen mit dem Netzwerkinventar und den deklarierten Subnetzen ab. Prüfen Sie vor der Standortzuordnung, über welche Verbindung die Adresse zustande kam. Das Fehlen dieses Ereignisses ersetzt den Inventarvergleich nicht, und sein Auftreten identifiziert keinen Angreifer.

Beobachtung	Als Nächstes zu erhebende Nachweise	Unterstützte Entscheidung
Client-Standort weicht vom erwarteten Standort ab	Aktuelle Adresse, Subnetzobjekt, Site-Zuordnung, Bestätigung durch die Netzwerkverantwortlichen	Zuordnung korrigieren oder erklären
Client verwendet einen DC an einem anderen Standort	Ergebnis einer erneuten Suche und dokumentiertes Niederlassungs-/WAN-Design	Ausnahme von einem unerwarteten Pfad unterscheiden
Standort scheint keine Server zu haben	Erfolgreicher Verzeichnis-Lesezugriff und unabhängiges DC-Inventar	Bewusstes Niederlassungsdesign von unvollständiger Erfassung unterscheiden
Standort hat ein zugeordnetes Subnetz, aber Clients bleiben ohne Zuordnung	Tatsächliche Client-Adressbereiche im Vergleich zum vollständigen Subnetzinventar	Fehlende Netze über das erste Subnetz des Standorts hinaus finden

Behebung: Zuordnung korrigieren oder beabsichtigte Ausnahme dokumentieren (Remediation)

1. Zuerst Unsicherheiten im Inventar klären

Gleichen Sie vor einer Topologieänderung die Collector-Momentaufnahme mit erfolgreichen Verzeichnis-Lesezugriffen ab. Wenn die Auflistung von Servern oder Subnetzen scheiterte, untersuchen Sie den Erfassungskontext und wiederholen Sie die Inventarisierung. Stellen Sie keinen DC bereit, löschen Sie keinen Standort und erfinden Sie kein Subnetz, nur um eine scheinbare Abwesenheit zu beseitigen, die aus einer fehlgeschlagenen Abfrage entstand.

Fragen Sie bei einem Standort ohne lokalen DC die Domänen- und Netzwerkverantwortlichen, ob dies beabsichtigt ist. Dokumentieren Sie den Standort des versorgenden DC, die erwartete WAN-Abhängigkeit, die verantwortliche Person und den Anlass für eine erneute Prüfung. Bewahren Sie diese Ausnahme zusammen mit den Client-Beobachtungen auf, damit spätere Prüfer verstehen, warum eine standortübergreifende Suche dort akzeptabel ist.

2. Eine bestätigte fehlende oder falsche Zuordnung korrigieren

Ermitteln Sie das tatsächliche Client-Netz und den vorhandenen Standort, der es repräsentieren soll. Prüfen Sie die vorgeschlagene Zuordnung mit den Netzwerkverantwortlichen, einschließlich weiterer möglicherweise betroffener Netze. Eine Subnetzdefinition sollte das vereinbarte Netzwerkdesign abbilden und nicht lediglich die Adresse des ersten Rechners kopieren, der einen Fehler meldete.

Für ein tatsächlich fehlendes Subnetz dokumentiert Microsoft dieses Erstellungsbeispiel unter New-ADReplicationSubnet:

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

Dies sind Microsofts Beispielnetz und -standort, keine vorgeschlagene Konfiguration für Ihre Umgebung. Setzen Sie ein verifiziertes Netz und einen vorhandenen vorgesehenen Standort erst ein, nachdem Sie bestätigt haben, dass das Subnetzobjekt tatsächlich fehlt. Bei einem vorhandenen Objekt mit falscher Zuordnung korrigieren Sie dessen Site-Zuordnung in Active Directory Sites and Services über Ihren normalen Änderungsprozess. Bewahren Sie die ursprünglichen Werte und den genehmigten Ersatz im Änderungsprotokoll auf.

Ist ein Server tatsächlich außer Betrieb genommen, folgen Sie dem separaten Leitfaden zur DC-Objekthygiene und Metadatenbereinigung. Bestätigen Sie die Außerbetriebnahme vor der Bereinigung. Eine leere erfasste Serverliste belegt nicht, dass ein aktiver DC entfernt werden sollte; Serverobjekte hinzuzufügen oder zu entfernen ersetzt nicht die Korrektur der Client-Subnetzzuordnung.

3. Repräsentative Clients erneut prüfen und Nachweise aufbewahren

Wiederholen Sie das Verzeichnisinventar und die Befehle zur Client-Suche, sobald die Änderung auf dem zur Validierung verwendeten Verzeichnisserver sichtbar ist. Testen Sie dieselben repräsentativen Netze, einschließlich der vorgesehenen Fälle mit entfernter Versorgung. Erfassen Sie für jeden Client den erwarteten Standort, den beobachteten Standort, den zurückgegebenen DC und die verbleibende Ausnahme.

Prüfen Sie den Anwendungsablauf erneut, der die Untersuchung ausgelöst hat, und betrachten Sie die Replikation separat, wenn die Topologie geändert wurde. Ein nicht mehr vorhandener Inventarbefund ist eine hilfreiche Bestätigung der erfassten Objekte, belegt aber nicht, dass nun jedes Netz oder jede Anwendung den gewünschten Pfad nutzt.

Wie EtcSec dies erkennt

Die Implementierung von etc-collector in EtcSec wertet anhand des erfassten Standort- und Subnetzinventars zwei Prüfungen der Kategorie Network aus:

SITE_TOPOLOGY_ISSUES — Low. site-topology.go:23 durchläuft data.Sites und erfasst jeden Standort mit len(site.Servers) == 0. Sie gibt einen Befund zurück, dessen Count die Anzahl dieser Standorte ist und deren Namen in sitesWithoutDc stehen. Bei einer positiven Anzahl ergänzt sie betroffene Standortentitäten. Sie gibt den Befund auch bei einer Anzahl von null zurück; in diesem Zweig gibt es keine Bedingung zu gemessener Latenz.
SUBNET_MISSING — Info. subnet-missing.go:24 durchsucht die erfassten Subnetze nach einem Subnet.SiteDN, das mit dem jeweiligen Site.DistinguishedName mittels strings.EqualFold übereinstimmt. Ein Standort ohne Übereinstimmung erhöht Count und wird in sitesWithoutSubnets aufgenommen; die Details enthalten außerdem die Gesamtanzahl der Standorte und Subnetze. Betroffene Standortentitäten werden nur ergänzt, wenn IncludeDetails aktiviert und die Anzahl positiv ist. Ein einziges zugeordnetes Subnetz erfüllt dieses Prädikat, selbst wenn andere tatsächlich genutzte Netze ohne Zuordnung bleiben.

Der LDAP-Provider ist für die Interpretation relevant. In client.go:1872 durchsucht GetSitesAndSubnets den Servers-Container jedes Standorts mit (objectClass=server). Obwohl der Kommentar nTDSDSA erwähnt, prüft der Code weder ein untergeordnetes NTDS Settings-Objekt noch den Gesundheitszustand des DC. Er fügt den dNSHostName eines Servers hinzu und verwendet ersatzweise name, jedoch nur, wenn ein nicht leerer Wert vorhanden ist.

Eine fehlgeschlagene Standortabfrage gibt einen Fehler zurück. Ein Fehler bei der Serverabfrage eines einzelnen Standorts wird ignoriert und kann Servers leer lassen. Eine fehlgeschlagene Subnetzabfrage gibt sites, nil, nil ohne Fehler zurück. Diese beiden letzten Zweige können in den an die Detektoren übergebenen Daten eine Abwesenheit vortäuschen. Eine scheinbar leere Standort- oder Subnetzliste erfordert deshalb unabhängige Nachweise aus einer erfolgreichen Inventarisierung.

Keine der beiden Prüfungen analysiert CIDR-Abdeckung, validiert Client-IP-Adressen, misst Latenz, bewertet Standortverknüpfungskosten oder Replikationsverbindungen oder testet die Erreichbarkeit eines DC. Keine beweist, dass jeder deklarierte Server ein gesunder DC ist. Ein bewusst ohne DC betriebener Standort kann den Low-Befund auslösen, während ein Standort mit einem Subnetz trotz Lücken an anderer Stelle nicht zum Info-Zähler beiträgt.