Da das Active Directory ein zentrales Element der meisten IT-Infrastrukturen ist, ist eine schnelle Wiederherstellung bei Fehlern eine der wichtigsten Anforderungen an die IT, um eine optimale Verfügbarkeit bieten zu können. Das ist aber nicht immer ganz einfach und erfordert eine genaue Planung im Vorfeld. Die kritische Rolle des Active Directory ergibt sich aus der Vielzahl von Aufgaben, die der Verzeichnisdienst übernimmt. Er hat ja nicht nur die Aufgabe, Informationen zu Benutzern und Gruppen bereitzustellen. Das Active Directory wird für die Authentifizierung von Benutzern benötigt. In ihm sind wichtige Teile der Gruppenrichtlinien abgelegt. Und die im Windows-Umfeld typischerweise genutzten Active-Directory-integrierten DNS-Server speichern auch die Informationen für die Lokalisierung von Servern im Active Directory. Ausserdem können auch Anwendungen auf dem Active Directory aufsetzen und kritische Informationen darin speichern. Beim Exchange Server hängt beispielsweise das Funktionieren der – unter dem Aspekt der Verfügbarkeit ebenfalls kritischen – E-Mail-Infrastruktur vom Active Directory ab.
Microsoft hat einiges getan, um die potentiellen Probleme zu minimieren. Typischerweise wird mit mehreren Domänencontrollern gearbeitet. Änderungen werden automatisch zwischen diesen repliziert. Damit gibt es beim Ausfall eines Domänencontrollers immer einen anderen Server, der als Ersatzsystem herangezogen werden kann.
Eine Einschränkung ist allerdings je nach Konfiguration der DNS-Dienst, weil die Daten dort nicht zwingend auf allen Domänencontrollern gespeichert werden. Auch andere Dienste, die mit Anwendungsverzeichnispartitionen arbeiten, können zumindest beim Ausfall mehrerer Domänencontroller – beispielsweise durch eine Nichterreichbarkeit wegen Netzwerkproblemen – nicht mehr funktionieren, obwohl zumindest noch einzelne Domänencontroller erreichbar sind.
Bei der Authentifizierung von Clients und der Verarbeitung von Gruppenrichtlinien wird standardmässig mit lokalen Kopien gearbeitet. So kann sich ein Benutzer mehrmals bei einem Client anmelden, auch wenn kein Domänencontroller zur Bestätigung der Anmeldung zur Verfügung steht. Dieses Verhalten kann allerdings von Administratoren angepasst werden, um eine höhere Sicherheit zu erreichen – deren Preis dann allerdings die niedrigere Verfügbarkeit ist.
Die Replikation ist also ein wichtiges Mittel, um möglichst immer verfügbare Domänencontroller zu haben. Sie ist aber gleichzeitig auch ein Risiko. Denn alle Änderungen werden automatisch auf alle Domänencontroller repliziert. Das bedeutet, dass auch fehlerhafte Änderungen wie das versehentliche Löschen von Daten schnell im Netzwerk verteilt werden. Sobald die Replikation gelaufen ist, hat man keine Instanz mehr, deren Daten noch im korrekten Zustand sind und auf die man damit zurückgreifen kann.
Hinzu kommt, dass die verteilte Struktur auch die Wiederherstellung von Daten komplexer macht als ein Restore auf einem lokalen System. Man könnte auch sagen, dass die Wiederherstellung eine der grössten Herausforderungen überhaupt beim Betrieb des Active Directory ist.
Neben der Sicherung und einer vorbereiteten Wiederherstellung, für die es genau definierte Vorgehensweisen geben muss, sind daher auch weitere organisatorische Regelungen unverzichtbar, mit denen man im Vorfeld die Risiken gravierender Fehler im Active Directory und damit die Notwendigkeit zur Wiederherstellung minimiert.
Änderungen im Active Directory dürfen grundsätzlich nur in genau festgelegten Prozessen erfolgen. In besonderem Masse gilt das für die strukturellen Anpassungen. Zu diesen zählen das Hinzufügen von Domänen, das Verschieben von OUs (Organizational Units, organisatorische Einheiten) und Schema-Änderungen. Vor solchen Massnahmen ist ein Backup ebenso zwingend wie eine genaue Planung. Nicht umsonst hat Microsoft für solche gravierenden Änderungen spezielle Gruppen wie die Schema-Admins und Organisations-Admins definiert.
Da das Active Directory auf einer permanent geöffneten Datenbank basiert, kann man diese nicht einfach sichern. Sicherungsprogramme, die das Active Directory sichern möchten, müssen vielmehr über eine spezielle API arbeiten. Diese stellt Kernfunktionen für die Sicherung und Wiederherstellung bereit, wobei grundsätzlich eine vollständige Sicherung erfolgt. Partielle Sicherungen nur von Änderungen werden nicht unterstützt. Eine der Anwendungen ist das Sicherungsprogramm des Windows Server 2003. Dort kann das Active Directory als Teil des Systemstatus oder System State gesichert werden. Neben dem Active Directory werden dadurch auch andere wichtige Informationen ausgelesen. Diese umfassen die Startdateien des Systems, die Registry, die Klassenregistrierungen für COM (Component Object Model) und das System Volume (SYSVOL), in dem sich beispielsweise Teile der Gruppenrichtlinien und die Anmeldeprogramme finden.
In welchem Intervall man die Sicherungen durchführt, gilt es nun zu überlegen. Abweichend vom häufig gewählten Ansatz einer täglichen inkrementellen Datensicherung muss man das Active Directory zumindest vollständig sichern. Die nächste Frage ist, ob eine solche tägliche Sicherung ausreicht. Für die Wiederherstellung sind kurze Sicherungszeiträume gut, weil man damit die Menge der wiederherzustellenden Daten beschränkt und eventuell um komplexe Ansätze für die Wiederherstellung herumkommt.
Ein Ansatz könnte die Sicherung zumindest einer Instanz des Active Directory pro Domäne im Intervall von drei Stunden und eine Aufbewahrung dieser Sicherungen über einen Zeitraum von mindestens 24 Stunden sein, zusätzlich mit einer Speicherung einer täglichen Sicherung über einen längeren Zeitraum. Da der Systemstatus vergleichsweise klein ist, wird dadurch auch nicht übermässig viel Speicherplatz beansprucht.
Im Ergebnis sollte man also für die Sicherung des Active Directory ein eigenes Konzept entwickeln, das auf die speziellen Anforderungen eingeht. Dazu gehört neben einem angepassten Sicherungsintervall die Sicherung vor grundlegenden Anpassungen an Domänencontrollern und der Active-Directory-Infrastruktur. Vor dem Einspielen von Hotfixes, Schema-Änderungen und Strukturanpassungen ist eine Sicherung unverzichtbar.
Auch vor einer Modifikation des Attributs tombstoneLifetime, das sich bei cn=Services, cn=Windows NT und dort wiederum bei cn=directory Service findet, muss eine Sicherung erfolgen. Dieses Attribut gibt an, wie lange gelöschte Objekte im Active Directory gespeichert bleiben, bevor sie endgültig gelöscht werden. Der Standardwert sind 60 Tage. Dieser Parameter beeinflusst die Nutzbarkeit von Backups. Eine Sicherung, die älter als der Wert des Attributs ist, ist nicht mehr für die Wiederherstellung brauchbar, da darin nicht mehr alle Löschungen von Objekten nachvollzogen werden können.
Ein weiterer wichtiger Parameter ist ab dem Service Pack 1 für den Windows Server 2003 die Einstellung Backup Latency Threshold (days). Dieser findet sich in der Registry unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters. Er wird normalerweise auf die Hälfte der tombstoneLifetime gesetzt. Dieser Wert kontrolliert die Durchführung von Sicherungen. Wenn er überschritten wird, wurde seit längerem – standardmässig sind 30 Tagen definiert – keine Sicherung durchgeführt. In diesem Fall wird ein Eintrag im Protokoll des Active Directory erzeugt.
Während die Sicherung recht einfach ist, kann die Wiederherstellung ein doch recht komplexes Unterfangen sein. Das Problem ist, dass das Active Directory ja nicht statisch ist, sondern sich permanent weiterentwickelt. Wenn man nun gezielt einzelne Objekte durch gesicherte Versionen überschreiben möchte, entsteht einiges an Planungs- und Steuerungsbedarf.
Grundsätzlich wird zwischen einer massgebenden (autoritativen) und einer nicht massgebenden Wiederherstellung unterschieden. Erstere überschreibt ausgewählte Werte auf anderen Domänencontrollern. Mit ihr lassen sich gelöschte oder versehentlich geänderte Objekte wiederherstellen. Für diese Objekte wird also der normale Replikationsmechanismus ausser Kraft gesetzt. Die nicht massgebende Wiederherstellung ist im Vergleich deutlich einfacher. Bei ihr wird ein Domänencontroller auf Basis einer Sicherung wieder hergestellt. Anschliessend empfängt er von anderen Domänencontrollern die Änderungen, die seit der letzten Sicherung angefallen sind.
Die beiden Konzepte, ihre Durchführung und weitere Ansätze für die Wiederherstellung werden im zweiten Teil der Serie ausführlich besprochen.
