AD-Wiederanlauf: Was ein Disaster-Recovery-Plan enthalten muss, damit man ihn nicht zum ersten Mal im Ernstfall liest

Solange Active Directory funktioniert, fällt kaum jemandem auf, wie viele Systeme eigentlich davon abhängen. Sobald es nicht mehr funktioniert, fällt es sehr schnell auf: Anmeldung, DNS, Server, Applikationen, Dateidienste, Administrationszugänge, Zertifikate, Automatisierung – im schlechtesten Fall verliert nicht nur ein einzelner Dienst den Betrieb, sondern ein großer Teil der IT gleichzeitig seine gemeinsame Identitätsbasis. Microsoft stellt deshalb einen eigenen Forest-Recovery-Leitfaden bereit und empfiehlt ausdrücklich, daraus einen auf die eigene Umgebung zugeschnittenen Plan abzuleiten und diesen regelmäßig zu testen. Nur: Ein Link auf diesen Leitfaden ist noch lange kein Disaster-Recovery-Plan.

Zuerst muss klar sein, welches Problem überhaupt vorliegt

Nicht jeder AD-Ausfall verlangt eine vollständige Forest Recovery, und dieser Unterschied ist entscheidend. Ein versehentlich gelöschtes Objekt ist ein anderes Problem als ein zerstörter Domain Controller, eine fehlerhafte Replikation, eine kompromittierte administrative Identität, eine forestweite Fehlkonfiguration oder ein Angriff auf sämtliche Domain Controller gleichzeitig. Microsoft bezeichnet die vollständige Forest Recovery ausdrücklich als Maßnahme für schwerwiegende, forestweite Ausfälle – in vielen Situationen als letzten möglichen Weg, nicht als ersten.

Ein Notfallplan braucht deshalb zuerst eine Entscheidungsmatrix: Was genau ist ausgefallen, wie weit reicht die Störung, ist die bestehende Umgebung noch vertrauenswürdig, und lässt sich reparieren oder muss aus einem bekannten guten Zustand wiederhergestellt werden? Die eigentliche technische Wiederherstellung darf erst beginnen, wenn diese Fragen beantwortet sind.

Welches Backup ist überhaupt vertrauenswürdig?

Bei einem gewöhnlichen Hardwaredefekt ist diese Frage einfach zu beantworten. Bei einem Sicherheitsvorfall ist sie es nicht – das neueste Backup ist dann nicht automatisch das beste. Wenn die Umgebung schon vor drei Tagen kompromittiert war, enthält ein Backup von gestern womöglich genau den Zustand, den man eigentlich loswerden will.

Der Recovery-Plan muss deshalb festlegen, wo die Backups liegen, welche Domain Controller gesichert werden, wie ihr Zustand überprüft wird, welche Aufbewahrungsfristen gelten, wer Zugriff darauf hat und wie ein wirklich vertrauenswürdiges Backup bestimmt wird. Bei einer Forest Recovery fällt Active Directory grundsätzlich auf den Stand des verwendeten Backups zurück, und alles, was danach passiert ist, kann verloren gehen – diese Konsequenz gehört unbedingt in die Wiederanlaufentscheidung, nicht erst in die Nachbetrachtung.

Welcher Domain Controller kommt zuerst?

Für jede Domäne sollte lange vor dem Ernstfall feststehen, welcher Domain Controller bevorzugt wiederhergestellt wird – nicht als spontane Entscheidung im Störungsfall, sondern dokumentiert mit Servername, Betriebssystem, FSMO-Rollen, DNS-Rolle, Global-Catalog-Status, Backupverfahren, Speicherort des Backups, dem vorgesehenen Wiederherstellungsweg und den nötigen Netzparametern. Microsoft empfiehlt, für einen vollständigen Forest mindestens einen Domain Controller pro Domäne aus einem verfügbaren Backup wiederherzustellen. Ein guter Plan trifft diese Auswahl im Voraus, nicht während der Störung.

Der erste Wiederanlauf läuft kontrolliert, nicht offen

Bei einem kompromittierten oder logisch zerstörten Forest darf die alte Umgebung nicht einfach wieder mit dem restaurierten Domain Controller kommunizieren dürfen. Der wiederhergestellte, vertrauenswürdige Zustand muss zunächst isoliert bleiben, damit ihn der beschädigte Zustand nicht sofort wieder beeinflusst. Deshalb muss ein Plan auch die scheinbar banalen Dinge regeln – Netzwerksegment, Switchports und VLANs, IP-Adressen, DNS, eine funktionsfähige Administrationsarbeitsstation, Installationsmedien, den Zugriff auf die Backups, benötigte Treiber und eine verlässliche Zeitquelle. Werden diese Punkte erst nach dem Ausfall organisiert, verlängert das die Recovery Time erheblich, und genau das ist der Moment, in dem ein guter Plan den entscheidenden Unterschied macht.

DNS gehört zwingend in den Plan

Active Directory und DNS hängen so eng zusammen, dass ein wiederhergestellter Domain Controller wenig nützt, wenn Namensauflösung und die nötigen AD-DNS-Daten anschließend nicht wie erwartet funktionieren. Microsoft behandelt die DNS-Konfiguration deshalb als eigenständigen Teil der Forest-Recovery-Prozedur, und ein eigener Notfallplan sollte dokumentieren, welche DNS-Zonen AD-integriert sind, welche Domain Controller DNS bereitstellen, welche Forwarder gebraucht werden, welche externen Namespaces relevant sind und welche DNS-Abhängigkeiten außerhalb von Active Directory bestehen.

SYSVOL darf nicht vergessen werden

Active Directory besteht nicht nur aus der NTDS.dit. Auch SYSVOL – und damit unter anderem die Dateibestandteile der Gruppenrichtlinien – muss konsistent wiederhergestellt werden. Bei DFSR-repliziertem SYSVOL sieht Microsoft dafür konkrete Verfahren für eine autoritative Synchronisierung beziehungsweise Wiederherstellung vor, und ein Disaster-Recovery-Plan muss genau festhalten, welches dieser Verfahren in der eigenen Umgebung vorgesehen ist – Schritt für Schritt, nicht als pauschaler Hinweis „SYSVOL wiederherstellen".

Krbtgt, Trusts und Zugangsdaten gehören zum Sicherheits-Recovery

Nach einem sicherheitsbedingten Forest Recovery reicht es nicht, dass die Domain Controller wieder laufen. Vertrauensbeziehungen und kryptografisch relevante Anmeldeinformationen müssen ebenfalls betrachtet werden – Microsoft sieht im Recovery-Prozess unter anderem das Zurücksetzen des krbtgt-Kennworts sowie, bei sicherheitsbedingtem Recovery, der Trust-Kennwörter vor. Darüber hinaus muss jede Organisation für sich klären, welche weiteren Zugangsdaten rotiert werden müssen: privilegierte Konten, Service Accounts, lokale Administratorkonten, Automatisierungscredentials, API-Secrets, Zertifikate und Konten externer Systeme. Genau das ist einer der Gründe, warum eine Forest Recovery deutlich mehr ist als ein simpler Restore.

Nicht einfach alle alten Domain Controller wieder einschalten

Nach Wiederherstellung des vertrauenswürdigen Kerns muss entschieden werden, wie die übrigen Domain Controller wieder bereitgestellt werden. Microsoft beschreibt sowohl das erneute Bereitstellen zusätzlicher Domain Controller als auch, bei virtualisierten DCs, geeignete Cloning-Verfahren. Gerade nach einer Kompromittierung ist ein Neuaufbau in meiner Erfahrung fast immer sauberer als die unkritische Rückkehr der alten Systeme – aber welche Methode zum Einsatz kommt, sollte lange vor dem Ernstfall feststehen, nicht während er läuft.

Nach Active Directory kommt die nächste Abhängigkeitsschicht

Wenn Active Directory wieder funktioniert, ist die Organisation damit noch lange nicht vollständig betriebsbereit. Jetzt beginnt die nächste Schicht: Active Directory und DNS, das Tier-0-Management, die PKI, zentrale Netzwerk- und Sicherheitsdienste, Virtualisierung und Storage, Managementsysteme, zentrale Applikationen, die Fachverfahren und schließlich die Clients und Benutzerzugriffe. Diese Reihenfolge ist nur ein Beispiel und muss für jede Umgebung individuell festgelegt werden – entscheidend ist, dass die Abhängigkeiten vor dem Ausfall analysiert wurden, nicht währenddessen.

Ein ungetesteter Plan ist bloß eine Hypothese

Das ist wahrscheinlich der wichtigste Punkt im ganzen Thema. Microsoft empfiehlt ausdrücklich, Forest-Recovery-Abläufe regelmäßig praktisch durchzuspielen, um zu prüfen, ob die eigenen Schritte noch funktionieren und ob die vorgesehenen Wiederherstellungs-DCs weiterhin die richtige Wahl sind. Ein Test muss dabei nicht jedes Mal die komplette Produktion betreffen – schon eine isolierte Recovery-Umgebung beantwortet zuverlässig, ob das Backup tatsächlich verwendbar ist, ob die Zugangsdaten verfügbar sind, ob die dokumentierten Befehle funktionieren, ob Software oder Treiber fehlen, ob DNS funktioniert, ob sich SYSVOL korrekt wiederherstellen lässt, ob die dokumentierten Abhängigkeiten stimmen und wie lange der Vorgang tatsächlich dauert.

Und vor allem eine Frage, die ich für die entscheidende halte: Kann das Team den Plan ausführen, ohne die Person anzurufen, die ihn geschrieben hat?

Was am Ende im Ordner liegen sollte

Ein vollständiger Satz an AD-Disaster-Recovery-Unterlagen sollte mindestens die aktuelle Forest- und Domainstruktur, die Liste der Domain Controller, die FSMO-Rollen, die DNS-Struktur, die Trusts, die Standort- und Subnetzstruktur, eine Backupübersicht, die Auswahl der Recovery-DCs, das DSRM-Verfahren, die nötigen Offline-Zugangsdaten, einen Netzwerkplan für die isolierte Wiederherstellung, die Recovery-Runbooks selbst, das SYSVOL-Verfahren, die Credential-Rotation, den Wiederaufbau weiterer Domain Controller, die Wiederanlaufreihenfolge der abhängigen Systeme, die Kommunikations- und Eskalationswege, die Abnahmekriterien und das Protokoll des letzten Recovery-Tests enthalten. Und dieser Satz an Unterlagen darf nicht ausgerechnet dort liegen, wo man nach einem AD-Ausfall nicht mehr darauf zugreifen kann – das klingt banal, ist mir aber schon mehr als einmal begegnet.

Fazit

Die Frage bei Active Directory ist nie, ob irgendwann etwas schiefgeht – ob es ein Hardwarefehler ist, eine Fehlkonfiguration, ein Bedienfehler oder ein Sicherheitsvorfall, spielt am Ende keine Rolle. Die Frage, die zählt, ist, ob man heute schon weiß, was man dann tut. Ein Disaster-Recovery-Plan nimmt dem Ernstfall nicht seine technische Schwierigkeit, aber er verhindert, dass unter maximalem Zeitdruck auch noch Architekturentscheidungen, Zugangsdaten, Abhängigkeiten und Wiederherstellungsverfahren neu recherchiert werden müssen. Ein Notfallhandbuch ist dann gut, wenn man es im Notfall benutzt – und nicht im Notfall zum ersten Mal schreibt.