Active Directory - Backup und Restore, Teil 2
Was dem AD alles zustoßen kann
Die Active-Directory-Sicherung muss kein Geheimnis pompöser Backup-Management-Suiten sein. Dass es auf Wunsch auch kostenfrei und übersichtlich geht, zeigt eine kleine Serie in der LANline. Teil 2 zeigt, wann und warum es zu AD-Pannen kommen kann.
Unter welchen Umständen ist beim Active Directory ein Restore notwendig? Zuerst sei der Ausfall
eines Domänen-Controllers (DC) erwähnt, der einfachste Fall. Vorausgesetzt, in der Domäne
existieren weitere Domänen-Controller, reicht es aus, einen neuen DC zu promoten, und der Griff zur
Datensicherung bleibt erspart. Einziger Stolperstein kann die in der Datenbank verbleibende
Namensreferenz des nicht mehr vorhandenen DCs sein. DCPROMO schlägt fehl, wenn in der Datenbank ein
DC mit dem verwendeten Namen bereits oder noch existiert. Es gibt zwei Möglichkeiten, mit diesem
Problem umzugehen: Wenn es schnell gehen soll, ist die beste Variante, den DC unter anderem Namen
ins AD zu nehmen. Der alte Name bleibt dann zwar weitrehin in der Datenbank – dies schmerzt aber
nicht, da der DC inaktiv ist. Der Eintrag lässt sich im Nachhinein bereinigen. Muss der Name des
DCs gleich bleiben, ist eine vorherige Bereinigung notwendig [2].
Schwieriger ist es, wenn alle DCs in Mitleidenschaft gezogen sind, also die ganze Domäne
betroffen ist. Gründe hierfür könnten sein: Eine korrupte Datenbank, ein Virenbefall oder eine
DoS-Attacke gegen die Domänen-Controller oder gar ein Brand im Serverraum. In solch einem Fall muss
ein Systemstate-Backup her, um die Domäne wiederherzustellen.
Das Recovery eines Domänen-Controllers oder einer Domäne ist je nach Umfeld und Aufbau des AD
eine komplexe Angelegenheit: Welche Domäne ist ausgefallen? War es eine Root-Domäne? Gibt es
Sub-Domänen? Bezogen auf Domänen-Controller sind die FSMO-Rollen von Bedeutung. Hatte der DC eine
dieser Rollen? Lässt sich bis zum Recovery auf die Rolle verzichten oder ist sie lebensnotwendig
für die Domäne? Hatte der DC weitere Funktionen wie Global Catalog oder DNS? Die Faktoren bedingen
verschiedene Reaktionen.
Komplett abgehandelt werden die Vorgehensweisen zur Wiederinbetriebnahme von Domänen und
Domänen-Controllern im Microsoft-Whitepaper "Planning for Active Directory Forest Recovery" [3]. Es
ist nicht notwendig, alle Reaktionen auf einen DC- oder Domänenausfall jederzeit parat zu haben,
dafür treten die entsprechenden Fälle zu selten auf. Man muss aber grob wissen, was im Schadensfall
zu tun ist und wo das zugehörige Verfahren im Detail beschrieben ist. Genau so wichtig ist die
Gewissheit, immer über einen aktuellen Systemstate-Backup zu verfügen.
Ein sehr viel häufigeres Ereignis, das eine Wiederherstellung notwendig macht, ist das
Restaurieren versehentlich gelöschter Kontenobjekte durch Fehlbedienungen oder fehlerhafte Skripts.
Der Schaden ist ist meist schnell spürbar, was eine ebenso schnelle Reaktion erfordert.
Damit beispielsweise für einen Anwender, dessen Konto gelöscht worden ist, schnell wieder alles
beim Alten ist, muss das Objekt über nicht-autorisierendes und autorisierendes Restore mittels
ntdsutil.exe hergestellt werden – ein zweistufiges Verfahren zum Restaurieren von gelöschten
Kontenobjekten. Dies gilt für alle genannten Objekttypen – Benutzer-, Computer- oder Gruppenobjekte
– gleichermaßen. Was die Vorgehensweise zweistufig macht, ist die Tatsache, dass ein gelöschtes
Konto – wie erwähnt – als gelöscht markiert ist und die Datenbank davon ausgeht, dass dies der
aktuelle Zustand dieses Objekts ist. Wird der DC im Active-Directory-Restore-Modus gebootet und der
Systemstate wiederhergestellt, wäre das Objekt nach Replikation mit den anderen DCs trotzdem wieder
gelöscht, da die aktuellste USN immer noch von dem DC stammt, auf dem der Löschvorgang erfolgte.
Aus diesem Grund ist nach dem nicht-autorisierendem Restore ein autorisierender Restore notwendig,
der die USN erhöht, sodass der Status des gelöschten Kontos nicht mehr "gelöscht" lautet. Der in
Folge 1 beschriebene Vorgang zum Erzeugen eines Tombstones wird umgekehrt – mit wesentlichen
Einschränkungen, wie noch zu sehen sein wird.
Wenn der DC im Active-Directory-Restore-Modus gebootet worden ist und ntdsutil geduldig auf die
Eingabe eines Befehls wartet, muss mit dem Restore-Kommando genau angegeben werden, was im
Einzelnen wiederzustellen ist. Spätestens jetzt muss dem Administrator der Pfad des verloren
gegangenen Objektes in Form des "Distinguished Name" (DN) bekannt sein. Der DN kennzeichnet den
Namen eines Objekts in einer Verzeichnisstruktur einschließlich der Ordnerhierarchie, in der das
Verzeichnisobjekt liegt. Ein Beispiel: Das Benutzerkonto mit dem Namen Hans Muschter aus der Domäne
"SecLab.local", das sich in der Organisationseinheit (OU) "Manager" befindet, hat folgenden DN: "
CN=Hans Muschter, OU=Manager,DC=SecLab,DC=local".
In flachen Strukturen mag der DN bekannt sein, aber in umfangreicheren Active Directories ist es
keine Seltenheit, wenn keiner mehr weiß ,in welcher OU das vermisste Konto vor dem Löschen lag. Für
diesen Fall lässt sich im Vorfeld Abhilfe schaffen, und zwar in dem über das Kommando dsquery.exe
täglich eine Textdatei mit allen DNs erzeugt wird (siehe Bild 1). Sinnvoll wäre es, den Befehl in
den Batch "DCBackup.cmd" zu integrieren. Die Liste mit DNs dient der Information, in welcher OU das
gelöschte Kontenobjekt lag. Nicht weniger nützlich ist es, die ganze Zeichenkette mit dem DN aus
der Textdatei über die Zwischenablage in ntdsutil.exe einfügen zu können, was die leidigen
Fehleingaben in ntdsutil.exe vermeidet (Bild 2). Nach Ausführung des Kommandos kann es sein, das
ntdsutil.exe einen Hinweis über nicht aufgelöste Referenzen meldet, sogenannte "Back-Links" (Bild
3). Back-Links werden im Active Directory verwendet, um unter anderem Benutzerkonten
Gruppenmitgliedschaften zuzuordnen. Diese sind nämlich nich beim Benutzerobjekt gespeichert,
sondern liegen dort nur als Referenz (Link) im Attribut "memberOf". Wird ein Benutzer- oder
Computerobjekt zum Tombstone (siehe Folge 1), entfernen Cleanup-Prozesse auf jedem DC alle
Back-Links. Somit lassen sich diese durch ntdsutil.exe auch nicht rekonstruieren, da es sich eben
nur um Referenzen gehandelt hat, die nicht mehr Bestandteil des Tombstones sind. Im konkreten Fall
des wiederhergestellten Benutzerobjekts heißt dies, dass das Konto zwar wieder vorhanden ist,
allerdings keine Gruppenmitgliedschaften mehr besitzt. Gleiches gilt für das Attribut "
directReports" (Registerkarte "Organization" in den "Benutzereigenschaften"), bei dem es sich
ebenfalls um einen Back-Link handelt.
Eine sehr interessante und weiterführende Dokumentation zu diesem Thema liefert Netpro [4].
Wichtig ist für uns an dieser Stelle, dass mit der aktuellen Version von ntdsutil.exe die fehlenden
Back-Links zu keinem bösen Erwachen führen, da das Tool neben den Warnhinweisen auch
LDIF-Importfiles erzeugt. Mit ldifde.exe lassen sich diese anwenden, nachdem der Domänen-Controller
wieder Online ist, um fehlende Back-Links herzustellen [5] (Bild 4). In einem Forest, der aus
mehreren Domänen besteht, ist es notwendig, ntdsutil.exe auf einem Global Catalog Server (GC)
auszuführen, da nur DCs die Global Catalog sind alle Referenzen anderer Domänen besitzen. Sonst
kann es geschehen, dass zwar die Mitgliedschaften aus der Benutzerdomäne in den LDIF-Files
berücksichtigt sind, nicht jedoch die aus benachbarten Domänen.
Lesen Sie mehr zum Thema
