AD-Gesamtstruktur-Wiederherstellung planen und üben

Die Gesamtstruktur-Wiederherstellung ist das Verfahren, das niemand ausführen möchte – weshalb die meisten Organisationen es nie ausgeführt haben. Sie ist das letzte Mittel, wenn Active Directory selbst nicht mehr vertrauenswürdig ist: von Ransomware verschlüsselte DCs, eine gesamtstrukturweite zerstörerische Änderung oder eine so tiefe Kompromittierung, dass kein DC für sauber erklärt werden kann. Microsofts Active Directory Forest Recovery Guide beschreibt das Verfahren im Detail. Ihn während eines Vorfalls zu lesen – mit stillstehendem Geschäft und der Geschäftsleitung in der Krisenrunde – ist der falsche Zeitpunkt, um festzustellen, dass Ihre DSRM-Kennwörter in einem Tresor liegen, der sich gegen AD authentifiziert.

Dieser Leitfaden macht aus Microsofts Verfahren ein eigenes, an Ihre Gesamtstruktur angepasstes Runbook und ein Übungsprogramm, das beweist, dass es funktioniert. Er setzt voraus, dass die Sicherungen aus dem Beitrag zum Schutz von AD-Sicherungen vor Ransomware existieren, und geht tiefer als der Überblick im Grundlagenartikel zu Bewertung, Sicherung und Wiederherstellung.

Messen: was der Plan wissen muss

Ein Wiederherstellungsplan besteht größtenteils aus Inventar. Sammeln und bewahren Sie offline auf, auf Papier und auf verschlüsselten Medien außerhalb von AD:

• Gesamtstrukturtopologie: jede Domäne, ihre DCs, deren Standorte, IP-Adressen und Betriebssystemversionen sowie welche DCs FSMO-Rollen und den globalen Katalog innehaben.
• Sicherungsübersicht: für jede Domäne, welche DCs gesichert werden, in welchem Format, wo die unveränderliche Kopie liegt und wie man sie ohne AD erreicht.
• Anmeldeinformationen: DSRM-Kennwörter der gesicherten DCs, Break-Glass-Konten für Hypervisoren, Speicher- und Backup-Konsolen, die nicht von AD abhängen, sowie das Verfahren für den Offline-Tresor.
• Abhängigkeiten: DNS, DHCP, AD CS, Entra Connect, AD FS, PAM und die Reihenfolge, in der Anwendungen zurückkehren müssen.
• Personen: namentlich benannte Verantwortliche für jede Phase, mit Stellvertretern, und eine Out-of-Band-Kommunikation, die nicht auf Exchange oder Teams mit Anmeldung über das kompromittierte AD angewiesen ist.

# Momentaufnahme der Topologie zum Ausdrucken und Aufbewahren mit dem Plan
Get-ADForest | Select-Object Name, ForestMode, SchemaMaster, DomainNamingMaster, Domains, GlobalCatalogs
Get-ADDomain | Select-Object DNSRoot, DomainMode, PDCEmulator, RIDMaster, InfrastructureMaster
Get-ADDomainController -Filter * | Select-Object HostName, Site, IPv4Address, OperatingSystem, IsGlobalCatalog, OperationMasterRoles
(Get-ADObject "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)" -Properties tombstoneLifetime).tombstoneLifetime

Ein leeres tombstoneLifetime bedeutet den alten Standardwert von 60 Tagen für Gesamtstrukturen, die vor Windows Server 2003 SP1 erstellt wurden. Später erstellte Gesamtstrukturen verwenden standardmäßig 180 Tage.

Entscheiden: Ist das eine Gesamtstruktur-Wiederherstellung?

Nehmen Sie die Entscheidungskriterien in den Plan auf, damit der Incident Commander nicht improvisieren muss:

Entscheiden Sie außerdem, welche Sicherung sauber ist. Bei langer Verweildauer des Angreifers kann die neueste Sicherung Persistenz enthalten: unberechtigte Admins, verändertes AdminSDHolder, SID-Verlauf, bösartige GPOs, Schlüssel, mit denen sich Golden Tickets erstellen lassen. Der Plan sollte benennen, wer diese Entscheidung trifft und auf welche Belege er sich stützt – typischerweise forensische Zeitleisten aus Ihrer Event-Forwarding-Pipeline.

Das Wiederherstellungsverfahren

Die folgende Reihenfolge folgt dem Leitfaden von Microsoft. Halten Sie Ihr Runbook an der aktuellen Version dieses Leitfadens ausgerichtet, nicht an dieser Zusammenfassung.

1. Den Clean Room aufbauen

Bauen Sie ein isoliertes Netzwerk ohne Route zur Produktion auf, mit sauberem Hypervisor oder sauberer Hardware, per Hash verifizierten sauberen Installationsmedien und Admin-Arbeitsstationen aus vertrauenswürdigen Images. Alles Weitere geschieht hier. Die wiederhergestellte Gesamtstruktur wird erst dann mit der Produktion verbunden, wenn Sie entscheiden, dass sie sauber ist.

2. Den ersten beschreibbaren DC der Gesamtstrukturstammdomäne wiederherstellen

Stellen Sie einen beschreibbaren DC aus der gewählten Sicherung wieder her, vorzugsweise einen, der globaler Katalog und DNS-Server war. Lässt sich der Server oder die VM des ursprünglichen DCs wiederverwenden, starten Sie ihn in den DSRM und stellen den Systemstatus wie unten beschrieben wieder her. Ist er nicht mehr vorhanden, führen Sie zunächst eine Bare-Metal-Wiederherstellung aus einer vollständigen Serversicherung auf isolierter Hardware durch und fahren dann im DSRM fort.

# Auf dem wiederherzustellenden DC in den DSRM neu starten
bcdedit /set safeboot dsrepair
shutdown /r /t 0

# Nach der Anmeldung mit dem DSRM-Konto
wbadmin get versions -backupTarget:E:
wbadmin start systemstaterecovery -version:09/20/2026-02:00 -backupTarget:E: -authsysvol -quiet

Dies ist eine nicht autoritative Wiederherstellung von AD DS mit autoritativer Wiederherstellung von SYSVOL. Der Schalter -authsysvol kennzeichnet das SYSVOL dieses DCs als primäre Kopie. Unterstützt die Wiederherstellungsmethode diesen Schalter nicht, setzen Sie vor dem Neustart msDFSR-Options auf CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=<DC>,OU=Domain Controllers,<domain DN> auf 1.

Verhindern Sie vor dem Verlassen des DSRM, dass der DC auf Replikationspartner wartet, die es nicht mehr gibt:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters' `
  -Name 'Repl Perform Initial Synchronizations' -Value 0 -Type DWord
bcdedit /deletevalue safeboot

3. Die Kontrolle über die Domäne übernehmen

Sobald der DC im normalen Modus läuft und sein DNS auf sich selbst zeigt:

• Übernehmen Sie jede FSMO-Rolle (Seizing), die von DCs gehalten wird, die nicht wiederhergestellt werden:

Move-ADDirectoryServerOperationMasterRole -Identity 'DC01' `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force

• Metadatenbereinigung für jeden anderen DC der Domäne. Das Löschen des Computerobjekts des DCs in Active Directory Users and Computers oder seines Serverobjekts in Active Directory Sites and Services führt die Bereinigung unter aktuellen Windows-Server-Versionen durch; die Metadatenbereinigung mit ntdsutil ist die Ausweichlösung. Entfernen Sie außerdem ihre DNS-Einträge sowie alle NS-Einträge und Delegierungen, die auf sie verweisen.
• Erhöhen Sie den RID-Pool um 100.000 auf dem RID-Manager-Objekt (rIDAvailablePool auf CN=RID Manager$,CN=System) und machen Sie den aktuellen RID-Pool auf dem wiederhergestellten DC ungültig. Beide Schritte verhindern doppelte SIDs für Objekte, die nach der Sicherung erstellt wurden.
• Setzen Sie das Kennwort des Computerkontos des wiederhergestellten DCs zurück und setzen Sie jede Seite jeder Vertrauensstellung zurück (netdom trust ... /resetOneSide), sobald die Partnerdomäne wiederhergestellt ist.

4. Anmeldeinformationen zurücksetzen

• Setzen Sie das krbtgt-Kennwort zweimal zurück. Bei einem einzigen DC gibt es keine Replikation abzuwarten, lassen Sie aber die erste Zurücksetzung abschließen, bevor Sie die zweite durchführen. Damit wird jedes mit den alten Schlüsseln signierte Ticket ungültig. Die Details finden Sie unter krbtgt-Kennwortrotation.
• Setzen Sie das Kennwort des integrierten Administrators und jedes Tier-0-Kontos zurück und deaktivieren Sie jedes Konto, für das Sie sich nicht verbürgen können.
• Planen Sie das Zurücksetzen aller Benutzerkennwörter, der Kennwörter von Dienstkonten und der gMSA-Schlüssel, falls die Sicherung gestohlen worden sein könnte. Die Sicherung enthält jeden Hash zum Zeitpunkt der Sicherung.

5. Die anderen Domänen wiederherstellen, dann neu aufbauen

Wiederholen Sie die Schritte 2 bis 4 für einen beschreibbaren DC in jeder Domäne, von der Gesamtstrukturstammdomäne aus nach unten. Sobald der Stamm läuft, können Domänen parallel wiederhergestellt werden. Folgen Sie den Schritten des Leitfadens zum globalen Katalog für Ihre Topologie, denn Benutzer können sich erst anmelden, wenn ein GC verfügbar ist. Danach stufen Sie neue DCs von sauberen Medien herauf. Stellen Sie keine weiteren Sicherungen wieder her. Verbinden Sie Standorte und Replikation schrittweise wieder und achten Sie auf eine erneute Infektion.

6. Vor dem Wiederverbinden aufräumen

Entfernen Sie die vom Forensikteam gefundene Persistenz, führen Sie erneut eine PingCastle-Bewertung und eine ACL-Prüfung durch und überprüfen Sie die Mitgliedschaften privilegierter Gruppen, bevor irgendwelcher Produktionsverkehr die wiederhergestellte Gesamtstruktur erreicht.

Überprüfen

Jeder Kontrollpunkt der Wiederherstellung braucht einen objektiven Test:

dcdiag /v /c /e /f:C:\Recovery\dcdiag.txt
repadmin /replsummary
repadmin /showrepl * /csv > C:\Recovery\showrepl.csv
Get-ADDomainController -Filter * | Select-Object HostName, OperationMasterRoles, IsGlobalCatalog

# SYSVOL: 4602 = autoritatives SYSVOL auf dem ersten DC initialisiert; 4604 = nicht autoritative Synchronisierung auf neuen DCs abgeschlossen
Get-WinEvent -FilterHashtable @{ LogName = 'DFS Replication'; Id = 4602, 4604, 4614 } -MaxEvents 10
Get-SmbShare | Where-Object Name -in 'SYSVOL','NETLOGON'

Ein DC mit 4614, aber ohne 4604 wartet noch auf die initiale SYSVOL-Replikation und gibt SYSVOL nicht frei. Das bedeutet meist, dass das SYSVOL des ersten DCs nie als autoritativ gekennzeichnet wurde.

Üben

• Tabletop, zweimal im Jahr. Gehen Sie das Runbook mit allen benannten Verantwortlichen durch. Prüfen Sie, ob jede Anmeldeinformation und jede Telefonnummer dort ist, wo der Plan es angibt, und ob nicht der Schritt irgendeiner Person stillschweigend von AD, E-Mail oder SSO abhängt.
• Technische Übung, jährlich. Stellen Sie echte Sicherungen aus der unveränderlichen Kopie in einem isolierten Labor wieder her und arbeiten Sie das Runbook bis zu einer funktionierenden Gesamtstruktur mit neuen DCs ab. Messen Sie die Zeit jeder Phase.
• Nach jeder Übung aktualisieren. Jede Übung bringt Korrekturen hervor: fehlende Treiber, falsche DSRM-Kennwörter, undokumentierte FSMO-Verteilung, Skripte, die einen bestimmten Betriebssystem-Build voraussetzten. Kommerzielle Werkzeuge zur Gesamtstruktur-Wiederherstellung (Semperis ADFR, Quest Recovery Manager for AD) können vieles davon automatisieren, müssen aber genauso geübt werden.

Was dadurch nicht mehr funktioniert

• Datenverlust bis zum Sicherungszeitpunkt. Jede Änderung nach der gewählten Sicherung ist verloren: neue Benutzer, Kennwortänderungen, Gruppenänderungen, Domänenbeitritte von Computern. Seitdem beigetretene oder neu verschlüsselte Computer können ihren sicheren Kanal verlieren und benötigen Test-ComputerSecureChannel -Repair oder einen erneuten Beitritt.
• Kerberos und Sitzungen. Das zweimalige Zurücksetzen von krbtgt macht alle Tickets ungültig. Jeder Benutzer und jeder Dienst authentifiziert sich neu, und lang laufende Dienste müssen möglicherweise neu gestartet werden.
• Hybride Identität. Entra Connect sieht das wiederhergestellte Verzeichnis als große Änderungsmenge. Versetzen Sie den Synchronisierungsserver in den Staging-Modus, prüfen Sie die ausstehenden Exporte und behalten Sie den Schwellenwert zum Schutz vor versehentlichem Löschen im Blick.
• Risiko bei Übungen. Ein wiederhergestellter DC, der versehentlich mit der Produktion verbunden wird, führt alte Kennwörter und verwaiste Objekte (Lingering Objects) wieder ein. Isolieren Sie das Labor physisch oder logisch und prüfen Sie dies vor jeder Übung.
• Zeit. Eine realistische Gesamtstruktur-Wiederherstellung für eine Gesamtstruktur mit mehreren Domänen dauert Tage, nicht Stunden. In Ihren Business-Continuity-Plan gehören die Zeiten aus den Übungen, nicht Wunsch-RTOs.

Weiterführende Lektüre: AD-Sicherungen vor Ransomware schützen stellt sicher, dass eine saubere Sicherung existiert, Tier 0 definieren listet alles auf, was mit der Gesamtstruktur zurückkehren muss, und der Bereich Bewertung, Sicherung & Wiederherstellung versammelt die gesamte Serie.