AD Domaenencontroller Inventar: FSMO-Metadaten prüfen

Was ein AD-Domänencontroller-Inventar belegt

Ein AD-Domänencontroller-Inventar sollte die DCs im untersuchten Umfang identifizieren und erklären, woher jeder Eintrag stammt. Namen, Betriebssysteme, Standorte, Schreibschutzkennzeichen, FSMO-Rollen und konfigurierte Replikationspartner helfen dem Administrator, das Verzeichnis zu verstehen. Für sich genommen beweisen sie jedoch weder, dass ein DC erreichbar ist, noch, dass alle erwarteten DCs erfasst wurden oder Verzeichnisänderungen erfolgreich repliziert werden.

Bei der praktischen Prüfung wird die Momentaufnahme des Collectors mit unabhängigen Verzeichnisabfragen abgeglichen. Domäne, abgefragter Server, Namenskontexte und Erfassungsfehler bleiben dabei erhalten. Eine leere FSMO-Liste muss von einer erfolgreichen Abfrage unterscheidbar bleiben, die zeigt, dass der betreffende DC keine Rolle hält. Ebenso ist ein konfigurierter Partner eine Topologieinformation und kein Nachweis erfolgreicher Replikation.

Dieser Leitfaden wurde am 4. Oktober 2026 anhand von Microsoft Learn und dem Quellcode von etc-collector geprüft. Die Befehle sind dokumentierte Beispiele für schreibgeschützte Prüfungen oder Anpassungen dokumentierter Syntax. Sie wurden nicht gegen ein Kundenverzeichnis ausgeführt. Der folgende Ablauf ist ein Vorschlag zur Prüfung von Nachweisen und kein Bericht über einen beobachteten Vorfall.

Wie Umfang und optionale Metadaten das Ergebnis beeinflussen

Beginnen Sie mit dem Erfassungsprotokoll statt allein mit der Anzeige. Identifizieren Sie angeforderte Domäne, LDAP-Endpunkt, BaseDN, Kontokontext, Erfassungszeit und Ausschlüsse. Bewahren Sie die tatsächlich bei den Abfragen verwendeten Namenskontexte auf, einschließlich des zur Anreicherung verwendeten Konfigurationskontexts. Eine Domänenbezeichnung ohne Server und Suchkontext erklärt nicht ausreichend, warum sich zwei Exporte unterscheiden.

Im untersuchten Collector werden DCs nach Anwendung der Ausschlüsse aus den erfassten Computerobjekten abgeleitet. Der Metadatenprovider reichert diese übergebene Liste an. Ein Partner, der keinem DC dieser Liste zugeordnet werden kann, wird daher möglicherweise im resultierenden Partnerfeld ausgelassen. Ein leeres Array kann somit eine unvollständige Zuordnung beschreiben, statt das Fehlen von Verbindungsobjekten zu belegen.

Der Provider bildet außerdem seine Konfigurationssuchbasis, indem er BaseDN das Präfix CN=Configuration, voranstellt. Prüfen Sie bei einer Erfassung in einer untergeordneten Domäne diesen konstruierten Kontext gegen den tatsächlichen Konfigurationskontext der Gesamtstruktur, den Ihre unabhängige Verzeichnisprüfung verwendet. Die mögliche Abweichung des Umfangs ist eine statische Schlussfolgerung aus dem Code und kein reproduzierter Fehler in einer Kundengesamtstruktur. Bewahren Sie Kontext und Suchergebnis auf, bevor Sie entscheiden, ob dies ein fehlendes Feld erklärt.

Ein nützliches Prüfprotokoll verbindet jede DC-Kennung mit ihrer Quelle und einem ausdrücklichen Abfragestatus. Vorgeschlagene Zustände sind erfolgreich gelesen, nicht erfasst, Abfrage fehlgeschlagen und noch nicht verifiziert. Dies sind Bezeichnungen für den Arbeitsablauf und keine vom Detektor ausgegebenen Werte. Wandeln Sie keinen der letztgenannten Zustände stillschweigend in eine leere Liste oder ein auf false gesetztes Kennzeichen um.

Inventarfeld	Zu vergleichender Nachweis	Zu vermeidende Schlussfolgerung
DC-Name und Domäne	Erfolgreiche unabhängige Auflistung für die angegebene Domäne	Eine erfasste Liste deckt jede Domäne der Gesamtstruktur ab
FSMO-Rollen	Rolleneigenschaften je DC sowie Rolleninhaber der Domäne und Gesamtstruktur	Ein leeres Feld beweist, dass eine Rolle keinen Inhaber hat
RODC-Kennzeichen	Unabhängige DC-Eigenschaften und Erfassungsstatus	Ein Standardwert ist eine verifizierte Einstufung als beschreibbarer DC
Standort	Verzeichniseigenschaften des DC und vorgesehene Standortzuordnung	Ein Standortname belegt erfolgreiche Replikation
Replikationspartner	Konfigurationsnachweise mit einer getrennten Abfrage des Replikationsstatus	Eine konfigurierte Verbindung beweist aktuell erfolgreiche Replikation

Erkennung: DCs und FSMO-Inhaber unabhängig abgleichen

1. Die vorgesehene Domäne auflisten

Verwenden Sie einen Verwaltungshost mit dem PowerShell-Modul ActiveDirectory und ein Konto, das zum Lesen der betreffenden Verzeichnisdaten berechtigt ist. Microsofts Referenz zu Get-ADDomainController dokumentiert den Parametersatz Filter und -Server. Die folgende Anpassung fragt DCs von einem ausdrücklich benannten Verzeichnisserver ab; ersetzen Sie den beispielhaften Hostnamen durch den verifizierten Server Ihrer Domäne:

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

Protokollieren Sie den tatsächlich abgefragten Server zusammen mit zurückgegebenen Objekten und Fehlern. Vergleichen Sie Kennungen und Domänenzugehörigkeit mit den Collector-Einträgen, bevor Sie Unterschiede bei der Anreicherung untersuchen. Halten Sie Objekte, die in einem der Exporte fehlen, als zu untersuchende Abweichungen fest, einschließlich bekannter Ausschlüsse, die einen Unterschied erklären.

Die Referenz unterscheidet Abfragen mit Filter oder Identity von der Ermittlung per Discovery. Ein Discovery-Aufruf findet einen DC, der seine Kriterien erfüllt; er listet nicht alle DCs auf. Bewahren Sie für eine Prüfung der gesamten Gesamtstruktur getrennte Domänenergebnisse auf. Die Referenz zu Get-ADForest enthält eine Auflistung über die Sammlung Domains der Gesamtstruktur. Bezeichnen Sie einen erfolgreichen Export einer einzelnen Domäne nicht als vollständige Abdeckung der Gesamtstruktur.

2. Rollen je DC lesen und mit der Inhaberschaft in Domäne und Gesamtstruktur abgleichen

Microsofts Seite zur FSMO-Verwaltung enthält dieses unveränderte Prüfbeispiel für die aktuelle Domäne:

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

Da dieses Beispiel den standardmäßigen Verbindungskontext verwendet, protokollieren Sie ihn ausdrücklich. Bevorzugen Sie für einen kontrollierten Vergleich die vorangehende, auf einen Server begrenzte Auflistung. Bewahren Sie die vollständig zurückgegebenen DC-Objekte zusammen mit der Rollenübersicht auf, damit eine Formatierungsentscheidung die Quellidentität nicht verdecken kann.

Die Dokumentation zu Get-ADDomain stellt PDCEmulator, RIDMaster und InfrastructureMaster bereit. Die Ausgabe von Get-ADForest enthält SchemaMaster und DomainNamingMaster. Diese schreibgeschützten Anpassungen verwenden die dokumentierten Parameter Identity und Server:

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

Setzen Sie die vorgesehene Domäne und Gesamtstruktur unabhängig voneinander ein; sie müssen nicht denselben DNS-Namen haben. Speichern Sie die vollständige Ausgabe einschließlich der zurückgegebenen Domänenidentität und Gesamtstrukturzugehörigkeit. Vergleichen Sie jeden Inhaber mit den Rolleneigenschaften je DC und den Metadaten des Collectors. Ein Gesamtstruktur-Rolleninhaber außerhalb einer Erfassung in einer untergeordneten Domäne ist eine Frage des Umfangs und kein Nachweis einer fehlenden Rolle.

3. Widersprüche und nicht gelesene Daten erhalten

Fügen Sie jeder Abweichung beide Ausgaben mit Erfassungszeiten, Serveridentitäten und Abfrageergebnissen bei. Eine erfolgreiche unabhängige Abfrage, die einen anderen Inhaber identifiziert, kann erklären, warum ein DC keine Rolle hält. Eine fehlgeschlagene Abfrage kann dies nicht. Wenn serverbezogene Abfragen voneinander abweichen, bewahren Sie beide auf, statt das Ergebnis auszuwählen, das das Inventar vollständig erscheinen lässt.

Benennen Sie einen Verantwortlichen zur Untersuchung des Erfassungskontexts und möglicher Verzeichnisinkonsistenzen. Die unmittelbare Nachweisfrage lautet, ob der fehlende Wert auf Umfang, Ausschluss, ungelesene Metadaten oder einen verifizierten Verzeichniszustand zurückgeht. Diese Frage sollte beantwortet werden, bevor eine Änderung an AD geplant wird.

Behebung: Nachweise vor Verzeichnisänderungen korrigieren (Remediation)

1. Erfassungslücken schließen und den Vergleich wiederholen

Prüfen Sie den protokollierten Endpunkt, die BaseDN der Domäne, den Konfigurationskontext, Ausschlüsse und Berechtigungen mit dem Verzeichnisverantwortlichen. Korrigieren Sie ein bestätigtes Problem des Erfassungskontexts über das unterstützte Konfigurationsverfahren des Collectors. Bewahren Sie die ursprüngliche Momentaufnahme, den Grund der Korrektur und die neuen Abfrageergebnisse zusammen auf.

Wiederholen Sie die oben genannten, auf den festgelegten Umfang begrenzten Befehle zur DC-Auflistung und Domänen-/Gesamtstrukturprüfung. Vergleichen Sie erneut dieselben Kennungen und Rolleneigenschaften. Bleiben Metadaten ungelesen, lassen Sie diesen Zustand sichtbar und weisen Sie die offene Untersuchung zu; das manuelle Ausfüllen des Berichtsfelds würde die Unterscheidung zwischen einer Verzeichnisabfrage und einer Annahme des Administrators zerstören.

Ein Abnahmeprotokoll sollte angeben, welche Domäne abgeglichen wurde, welche DCs ungeklärt bleiben, welche Rolleninhaber unabhängig gelesen wurden und welche Felder weiterhin unbekannt sind. Behandeln Sie einen ausgeschlossenen DC als ausgeschlossen, statt ihn als im Verzeichnis nicht vorhanden zu melden. Eine erfolgreich wiederholte Erfassung ist ein nützlicher Nachweis, erweitert ihren Umfang aber nicht über die tatsächlich abgefragten Domänen und Kontexte hinaus.

2. Replikation als eigenständige Kontrolle prüfen

Microsofts Leitfaden zur Fehlerbehebung bei Replikation dokumentiert diesen unveränderten Befehl aus einer Eingabeaufforderung mit erhöhten Rechten:

repadmin /showrepl * /csv > showrepl.csv

Das dokumentierte Verfahren erfordert die Mitgliedschaft in Enterprise Admins oder gleichwertige Rechte. Folgen Sie dem autorisierten Diagnoseverfahren Ihrer Organisation. Bewahren Sie die CSV-Datei und Befehlsfehler auf. Prüfen Sie Quellpartner, Namenskontexte, Informationen zum letzten Erfolg und Fehler getrennt von der Liste konfigurierter Partner im Inventar.

Derselbe Leitfaden benennt das Ereignisprotokoll Directory Service und die Repadmin-Ausgabe als Nachweise zur Fehlerbehebung. Verwenden Sie den tatsächlichen Fehlertext, um ein fehlgeschlagenes Diagnoseergebnis zu untersuchen. Eine im Inventar aufgeführte Verbindung beantwortet diese Zustandsfragen nicht. Ein nicht erreichbares Diagnoseziel bleibt ungeklärt, auch wenn andere DCs eine Ausgabe zurückgaben.

Protokollieren Sie Umfang und Ergebnis der Replikationsprüfung in einem eigenen Nachweisdokument. Ersetzen Sie das Feld der konfigurierten Partner nicht durch ein Zustandsurteil und stufen Sie nicht alle Verbindungen als fehlerfrei ein, weil eine Abfrage erfolgreich war. Dieser Inventarartikel schreibt aus einer Metadatenlücke heraus weder Topologieänderungen noch Wiederherstellungsmaßnahmen vor.

3. Qualifiziertes Inventar mit Topologie- und Wiederherstellungsplanung verbinden

Verwenden Sie die verifizierten Standortinformationen zusammen mit der DC-Auswahl durch Clients und der Zuordnung von Subnetzen zu Standorten. Diese Prüfung gleicht die Verzeichnistopologie mit tatsächlichen Clientnetzen und Discovery-Beobachtungen ab. Ein inventarisierter Standortname allein beweist weder eine geeignete Clientauswahl noch einen fehlerfreien Replikationszustand.

Stellen Sie das abgeglichene Protokoll der DCs und Rolleninhaber als Eingabe für die Planung der Gesamtstrukturwiederherstellung und Backup-Validierung bereit. Die Wiederherstellungsvorbereitung benötigt bekannte DCs und Rollen, aber auch Backup-Auswahl, Wiederherstellungsnachweise und ein umgebungsspezifisches Betriebshandbuch. Ein Inventarexport validiert keine Wiederherstellung und belegt nicht, dass der wiederhergestellte Verzeichniszustand vertrauenswürdig ist.

Wie EtcSec dies erkennt

EtcSecs etc-collector gibt INFO_DOMAIN_CONTROLLER als Inventarbefund aus. Die untersuchte Implementierung in dc-inventory.go erzeugt einen Befund der Stufe Info mit Count 1 je erfasstem DC. Wenn die übergebene DC-Liste leer ist, gibt sie keine Befunde zurück. Dieses Verhalten ist kein Schwachstellenurteil und beweist nicht, dass ein Verzeichnis ohne zurückgegebene Einträge keine DCs besitzt.

Detaillierte betroffene Entitäten werden nur mit IncludeDetails angehängt. Sie enthalten die grundlegenden Computeridentitäts- und Betriebssystemfelder sowie optional FSMO-Rollen, RODC-Status, Standort und Replikationspartner. Fehlende Anreicherung hinterlässt leere Arrays oder Standardwerte. Verbraucher müssen diese Werte qualifizieren, bevor sie sie als erfolgreiche negative Beobachtungen behandeln.

Der LDAP-Provider liest mit GetDCMetadata Rolleninhaberobjekte und NTDS-/Verbindungskonfiguration. FSMO-Suchfehler oder leere Ergebnisse werden übersprungen. Ein NTDS-Suchfehler lässt Standort- und Partnerfelder unausgefüllt, während das RODC-Kennzeichen und bereits gelesene Rollen verfügbar bleiben; Fehler bei der Verbindungssuche werden ignoriert. Partnerkennungen werden auf die übergebene DC-Liste zurückgeführt. Die Engine weist außerdem DCInfo nur zu, wenn der Metadatenaufruf erfolgreich ist.

Dies sind im Quellcode bei Commit afca1b9f7bba6f076d6a6493371486071001452b beobachtete Grenzen und keine reproduzierten Kundenfehler. Die Prüfung testet keinen Replikationszustand, misst keinen erfolgreichen Austausch von Änderungen und entscheidet nicht über die Wiederherstellungsbereitschaft. Verwenden Sie sie zur Darstellung erfasster DC-Systeme und qualifizieren Sie anschließend Abdeckung und optionale Metadaten mit den oben beschriebenen unabhängigen Abfragen.