Es gibt zwei Grundszenarien, die eine Wiederherstellung der Active-Directory-Datenbank nötig machen:
-
der Komplettausfall eines Domänencontrollers, sodass die Daten vollständig vom Band wieder eingespielt werden müssen
-
ein Fehler eines Administrators, der den partiellen oder gesamten Verlust von Active Directory zur Folge hat
Im ersten Szenario erfolgt die Bandwiederherstellung der Systemstatusdateien (zu denen Active Directory gehört) in Verbindung mit einer Wiederherstellung des Betriebssystems. Wenn der frisch wiederhergestellte Domänencontroller wieder online geht, aktualisieren ihn seine Replikationspartner mit den Änderungen, die es seit der Erstellung des Backups gab. Deswegen können Sie auch von einem älteren Band wiederherstellen, falls es Probleme mit dem Band von letzter Nacht gibt.
Der Workshop basiert auf Kapitel Zehn des Standardwerks „Windows Server 2003 für Insider“ von William Boswell aus dem Verlag Markt + Technik. Sie können dieses über 1300 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 1: Ausfall eines DNS-Servers und eines Domänencontrollers |
|
Teil 2: Ausfall eines FSMO-Rollenmasters |
|
Teil 4: Active Directory-Pflege |
|
Teil 5: Active Directory wiederherstellen |
Autoritative Wiederherstellung
Eine Standard-Systemstatus-Wiederherstellung holt Objekte zurück, die aus Active Directory gelöscht wurden. Wenn der frisch wiederhergestellte Domänencontroller nun von seinen Partnern repliziert, werden die wiederhergestellten Objekte umgehend wieder in den Deleted Objects-Container verschoben, und die ganze Arbeit war umsonst.
Wenn Sie einen Teil von Active Directory wiederherstellen müssen (ein einzelnes Objekt oder eine versehentlich gelöschte OU) oder auch (im Falle einer irreparablen Beschädigung) die ganze Datenbank, so müssen Sie dafür sorgen, dass die Objekte und ihre Eigenschaften auf dem Band auf die anderen Domänencontroller repliziert werden. Genau das leistet eine autoritative Wiederherstellung.
Eine autoritative Wiederherstellung ist eigentlich gar keine Wiederherstellung. Sie wird nach der eigentlichen Bandwiederherstellung durchgeführt und markiert die Objekte, die in den Repliken auf den anderen Domänencontrollern überschrieben werden sollen. Das geschieht, indem 100.000 zu den PVNs der einzelnen Eigenschaften der autoritativ wiederhergestellten Objekte addiert wird.
Im Folgenden finden Sie ein Repadmin-Beispiellisting, das zeigt, wie ein Benutzerobjekt vor und nach einer autoritativen Wiederherstellung aussieht. Das Attribut ObjectClass wird bei der autoritativen Wiederherstellung nicht angerührt, da es ein speziell für die Indizierung benötigtes Objekt ist.
Lassen Sie größte Vorsicht walten, wenn Sie eine autoritative Wiederherstellung des Konfigurations-Namenskontexts oder der ganzen Active Directory-Datenbank durchführen. Tun Sie dies ja nicht, wenn Ihnen auch nur im Entferntesten unklar sein könnte, was die Konsequenzen des Überschreibens von Systemkonfigurationsparametern sein könnten. Das gilt ganz besonders, wenn Sie Exchange 2000 oder andere Active Directory-abhängige Applikationen laufen haben. Sie brauchen nicht die ganze Datenbank wiederherzustellen, um nur eine OU zurückzukriegen. Seien Sie ruhig wählerisch.
DSRM-Passwort
Wenn Sie Active Directory bei einem Domänencontroller wiederherstellen, müssen Sie sich bei diesem Server mit dem Administratorkonto im lokalen SAM anmelden. Vielleicht kennen Sie aber das Passwort nicht.
Deswegen hat Microsoft ein neues Feature in das Utility Ntdsutil eingebaut, mit dem das lokale Administratorpasswort geändert werden kann. Dieses Feature heißt Reset DSRM (Directory Services Restore Mode) Administrator Passwort. Mit Administratorrechten auf einem Domänencontroller können Sie dieses Feature verwenden, um das Administratorkonto im SAM des Domänencontrollers zu ändern.
Wer darf Active Directory wiederherstellen?
Wenn Sie eine verteilte IT-Organisation mit Administratoren auf der ganzen Welt haben, könnte sich Ihnen die Frage stellen, wer eine Verzeichnis-Wiederherstellung durchführen kann. Es sollte klar sein, dass nur qualifizierte Leute Bandwiederherstellungen auf Domänencontrollern durchführen dürfen. Und Sie sollten auch wissen, ob Sie ein Problem beseitigen können, ohne die zentrale IT-Abteilung jenseits des Atlantiks anzurufen.
Die Durchführung einer Systemstatus-Wiederherstellung (was auch die Active Directory-Datenbank umfasst) erfordert das lokale Administratorpasswort im SAM auf dem Domänencontroller. Dieses Passwort heißt Directory Service Recovery Password. Wenn Sie dieses Passwort kennen, dann können Sie eine autoritative Wiederherstellung eines Teils oder der ganzen AD-Datenbank vornehmen, und zwar unabhängig davon, ob Sie nun Rechte über einen bestimmten Teil des Verzeichnisses haben oder nicht. Schließlich läuft ja der Active Directory-Dienst nicht, während Sie die autoritative Wiederherstellung durchführen, und so hat das System keine Chance, Ihre Anmeldedaten abzufragen und zu validieren.
Sie sollten das lokale Administratorpasswort von Domänencontrollern scharf bewachen und es oft austauschen. Andererseits kann jeder, der physikalischen Zugriff auf einen Domänercontroller hat, dort mit einem Utility wie ERD-Commander das lokale Administratorpasswort festlegen und vollen Zugriff erhalten. Unternehmen Sie Folgendes, um Ihre AD-Datenbank zu schützen:
-
Geben Sie nur den zuverlässigsten Administratoren das Recht, den Systemstatus auf Domänencontrollern wiederherzustellen.
-
Sichern Sie den Systemstatus nur auf wenigen, ausgewählten Domänencontrollern. Die Administratoren, die diese Backups durchführen, sollten zu den zuverlässigsten Leuten der Firma gehören.
-
Verhindern Sie den physikalischen Zugriff auf Domänencontroller an entfernten Standorten. Setzen Sie Headless-Server ohne Disketten- und CD-ROM-Laufwerk ein.
Zeitlimit für Backupbänder
Das passiert jeder IT-Abteilung irgendwann. Sie wollen ein Band einspielen und merken, dass die Bänder von letzter Nacht entweder nicht lesbar sind oder das Backup nicht durchgeführt wurde. Sie gehen nochmal zur Bibliothek und stellen fest, dass manche Bänder so alt sind, dass Sie die Sonne durch die Oxidschicht sehen können. Und ein paar der brauchbaren Bänder klemmten im Laufwerk, und es wurde überhaupt nichts auf sie geschrieben. Irgendwann finden Sie ein benutzbares Band, aber das ist dann schon ein bis zwei Wochen alt. Und Sie stehen da und fragen sich, ob Sie wirklich Active Directory von diesem Band wiederherstellen können.
Die gute Nachricht ist, dass Sie den Systemstatus von einem etwas älteren Band einspielen können, ohne Active Directory zu gefährden. Sobald die Systemstatus-Wiederherstellung abgeschlossen ist und Sie den Domänencontroller neu starten, erhält die wiederhergestellte Kopie von Active Directory Updates von den Replikationspartnern und wird uptodate gebracht. Wenn Sie dagegen eine autoritative Wiederherstellung durchführen, verlieren Sie alle zwischenzeitlichen Änderungen wie geänderte Passwörter, Veränderungen an Gruppenmitgliedschaften, neue Domänentrusts usw. Sie müssen also sehr vorsichtig damit sein, ein älteres Band für eine autoritative Wiederherstellung zu verwenden.
Tombstone-Lebensdauer
Es gibt zwei Grenzen, die der Verwendung einer älteren Kopie von Active Directory gesetzt sind. Die erste Grenze ist die Tombstone-Lebensdauer von gelöschten AD-Objekten.
Wenn ein AD-Objekt gelöscht wird, erlebt es zunächst so eine Art Fegefeuer. Das Objekt wird all seiner Attribute (mit wenigen Ausnahmen) entkleidet und in die Tiefen des Containers Deleted Objects geschleudert, in dem es 60 Tage lang sitzt und fault. Am Ende der 60 Tage – der voreingestellten Tombstone-Lebensdauer – wird das Objekt vom Garbage-Collection-Prozess endgültig aus der Datenbank entfernt.
Das bedeutet, dass Sie auf keinen Fall den Systemstatus (und damit Active Directory) von einem Band installieren dürfen, das älter als 60 Tage ist. Lassen Sie sich das Risiko anhand eines Beispiels erklären.
Angenommen, Sie löschen ein Objekt aus AD und führen dann eine Systemstatus-Wiederherstellung mit dem Band von letzter Nacht durch. Wenn Sie kein autoritatives Backup durchführen, wird das Objekt sofort wieder gelöscht, sobald der Domänencontroller Updates von seinen Replikationspartnern zieht. Das Update sagt: „Dieses Objekt ist bei mir im Container Deleted Objects. Verschiebe auch du deine Kopie des Objekts in den Container Delected Objects.“
Fehlerquelle 60-Tage-Frist
Doch wenn Sie von einem Band wiederherstellen, das älter als 60 Tage ist, dann werden die Replikationspartner den Tombstone aus dem Deleted Objects-Container entfernt haben. Dann gibt es keine Möglichkeit mehr, mit der der frisch wiederhergestellte Domänencontroller angewiesen werden könnte, das alte Objekt zu löschen. Die frisch wiederhergestellten Objekte werden zu Untoten. Sie sind aus allen Repliken des Namenskontexts gelöscht, außer der des wiederhergestellten Computers. Mit anderen Worten: Die Active Directory-Datenbank ist nicht mehr konsistent.
Vergessen Sie niemals diese 60-Tage-Frist. Hüten Sie sich vor Wiederherstellungsplänen, die eine ältere Kopie des Active Directory in Ihr System einspielen könnten. Machen Sie etwa keine Images von Domänencontrollern für Katastrophenfälle. Die CD mit dem Image wird am Tag 61 von Ihrem besten Freund zu Ihrem schlimmsten Albtraum. Wenn Sie Images in Ihre Wiederherstellungsstrategie integrieren wollen, dann machen Sie das Image vor der Hochstufung des Servers zum Domänencontroller. Stellen Sie das Image wieder her und stufen Sie dann den Rechner zum Domänencontroller hoch. Das repliziert eine frische Kopie des Verzeichnisses von einem anderen Domänencontroller.
Wenn Sie alle Kopien von Active Directory bei einer Katastrophe verlieren, dann bleibt Ihnen nichts anderes übrig, als das neueste Band einzuspielen und dann alle Änderungen durchzuführen, die es in der Zwischenzeit gegeben hatte, wie Passwortänderungen oder Änderungen von Gruppenmitgliedschaften.
Wiederherstellungen von Active Directory und Vertrauensstellungen
Es gibt noch ein zweites Limit für Systemstatus-Wiederherstellungen von älteren Bändern. Externe Vertrauensstellungen zu anderen Forests oder NT-Domänen verwenden Passwörter, die sich alle 7 Tage ändern. Wenn ein neues Passwort ausgehandelt wird, wird das alte Passwort nicht einfach vergessen, sondern gespeichert. Werden jedoch die Passwörter von einem Band wiederhergestellt, das älter als 14 Tage ist, dann müssen Sie die externen Trusts überprüfen und eine Neuverhandlung des Passworts erzwingen. Schlimmstenfalls müssen Sie den Trust entfernen und neu einrichten.
FRS (File Replication Service) repliziert den Inhalt von Sysvol bei allen Domänencontrollern der Domäne. Wenn Sie die GPC-Objekte in Active Directory autoritativ wiederherstellen, ohne Sysvol in den Zustand zurückzuführen, in dem es zum Zeitpunkt des Systemstatus-Backups war, dann riskieren Sie eine Differenz zwischen den GPC-Objekten in AD und den GPT-Dateien in Sysvol.
Autoritative Wiederherstellung und Sysvol
Es gibt keine autoritative Wiederherstellung von Sysvol. Stattdessen müssen Sie eine Kopie der Systemstatus-Dateien inklusive der Sysvol-Dateien an eine andere Stelle wiederherstellen und dann die Sysvol-Dateien herüberkopieren, nachdem Sie nach einer autoritativen Wiederherstellung von AD neu starten. Dies wird folgendermaßen durchgeführt:
1. Führen Sie eine normale Systemstatus-Wiederherstellung an den Original-Ort durch. Booten Sie nicht neu!
2. Führen Sie eine zweite Systemstatus-Wiederherstellung an einen anderen Ort durch. Dies schützt die älteren Sysvol-Dateien, damit Sie diese nach dem Neustart verwenden können.
3. Führen Sie eine autoritative Wiederherstellung der AD-Objekte oder -Container durch, die Sie zurückhaben wollen. Darunter sollten sich Objekte befinden, die mit Gruppenrichtlinien zu tun haben – denn ansonsten sind Sie in der falschen Schrittfolge gelandet und haben gar keinen Grund, sich wegen Sysvol Sorgen zu machen.
4. Lassen Sie den Domänencontroller neu booten und sehen Sie zu, dass der Sysvol-Inhalt von den Replikationspartnern aktualisiert wird. Das ist sehr wichtig. Sie dürfen erst dann weitermachen, wenn beim Inhalt von Sysvol auf allen Domänencontrollern volle Konvergenz erreicht ist.
5. Kopieren Sie nun auf dem Domänencontroller, auf dem Sie die autoritative Wiederherstellung durchführten, den Inhalt von Sysvol von dem alternativen Ort in das Standard-Sysvol. Damit überschreiben Sie die vorhandenen Dateien. Sie können auch die Ordner Policies und Scripts löschen und sie vom Alternativort herüberkopieren, wenn Sie alle GPT-Dateien entfernen wollen.
6. Warten Sie wiederum, bis beim Inhalt von Sysvol Konvergenz bei den Domänencontrollern erreicht ist.
7. Prüfen Sie nach, ob die Clients die richtigen Gruppenrichtlinien erhalten.
Einen Systemstatus wieder einspielen
Wenn Sie den Systemstatus wieder einspielen, überschreiben Sie die vorhandenen Dateien auf dem Rechner. Viele der Systemstatus-Dateien sind Datenbanken, die im laufenden Betrieb des Servers gewöhnlich gesperrt sind. Das gilt für die Active Directory-Datenbank, die Registry-Zweige, die Zertifikatdatenbank und andere.
Sie müssen also für die Systemstatus-Wiederherstellung den Rechner in eine Konfiguration booten, in der diese Datenbanken nicht laufen. Dies ist der Verzeichnisdienst-Wiederherstellungs-Modus (Directory Service Restore Mode, DSRM) eine der Optionen des abgesicherten Modus von Windows. Drücken Sie beim Standard-Bootmenü auf (F8) und wählen Sie dann diese Option aus dem Menü. Falls Sie kein Bootmenü sehen, drücken Sie unmittelbar nach dem POST auf (F8). Damit ist die gedrückte Taste im Tastaturpuffer und wird erkannt, sobald Ntldr startet.
Der DSRM lädt die Netzwerktreiber, sodass Sie eine Bandwiederherstellung über das Netzwerk vornehmen können; er aktiviert aber weder Active Directory noch sonst irgendeine andere kritische Datenbank. Dieser Modus setzt die Umgebungsvariable SAFEBOOT_OPTION auf DSREPAIR. Diese Variable muss gesetzt sein, denn sonst führt Ntdsutil keine autoritative Wiederherstellung durch.
Da im DSRM Active Directory nicht verfügbar ist, müssen Sie das Passwort des Administratorkontos im lokalen SAM eingeben. Das ist das Passwort, das Sie eingaben, als der Server zum Domänencontroller befördert wurde.
Das DSRM-Passwort ändern
Wenn Sie das DSRM-Passwort vergessen oder einen Server übernommen haben, bei dem Sie nicht wissen, was bei Dcpromo als Passwort eingegeben wurde, so können Sie das Passwort mit einem Utility von SysInternals (www.sysinternals.com) namens ERD Commander ändern. Es gibt zwei Versionen dieses Utilitys. Die kostenlose Version kann das Administratorpasswort nicht ändern, die kostenpflichtige dagegen schon.
Tipp: Sie könnten solche Passwörter auf einem Zettel notieren, den Sie dann im Servergehäuse einschließen. Auch ein Ausdruck der Datenträgerverwaltung wäre nützlich; vielleicht braucht irgendwann ein anderer Administrator das ursprüngliche Partitionslayout, um einen Festplattenfehler zu beheben.
Wenn Sie sich im abgesicherten Modus befinden, führen Sie die Systemstatus-Wiederherstellung wie folgt durch:
1. Starten Sie auf dem Domänencontroller, auf dem Sie Active Directory wiederherstellen wollen, das System im DSRM.
2. Legen Sie das Backupband mit den Systemstatus-Dateien ein.
3. Öffnen Sie das AUSFÜHREN-Fenster und geben Sie Ntbackup ein.
4. Wählen Sie den Reiter MEDIEN WIEDERHERSTELLEN UND VERWALTEN.
5. Erweitern Sie den Baum, bis Sie das Laufwerk und eine Liste früherer Jobs sehen. Wenn Sie den Baum beim Band-Symbol erweitern, müssen Sie u.U. ein Weilchen warten, bis das Band zurückgespult ist. Wenn Sie einen Katalog auf Festplatte haben, wird das System die Signatur im Katalog mit der Signatur auf dem Band vergleichen. Haben Sie keinen Katalog auf Festplatte, müssen Sie das Band katalogisieren. Klicken Sie das Medium mit der rechten Maustaste an und wählen Sie KATALOG.
6. In dem Baum, den der Bandkatalog anzeigt, setzen Sie die Option SYSTEM STATE.
7. Klicken Sie auf WIEDERHERSTELLUNG STARTEN. Eine Meldung weist Sie darauf hin, dass die Systemstatusdateien stets die vorhandenen Dateien überschreiben, wenn Sie nicht an einen Alternativort wiederherstellen wollen. Sie sollten nicht an Alternativorte wiederherstellen, weil fürs manuelle Kopien zu viele Dateien und zu viele Variablen involviert wären. Halten Sie den Atem an und lassen Sie das System überschreiben.
8. Klicken Sie auf JA, um die Meldung zu bestätigen. Das Bandlaufwerk macht sich an die Arbeit.
9. Nachdem die Wiederherstellung vollzogen wurde, klicken Sie auf BERICHT und sehen sich das Protokoll an, um sicherzugehen, dass alle Dateien fehlerfrei wiederhergestellt wurden.
10. Schließen Sie den Editor und das Wiederherstellungsfenster. Ihnen wird ein Neustart angeboten. Lehnen Sie das ab. Klicken Sie auf NEIN und schließen Sie das Backup-Programm.
Die Systemstatus-Wiederherstellung ist nun vollzogen. Wenn Sie nicht einzelne Objekte oder Container wiederherstellen wollen, können Sie den Domänencontroller neu starten und die Veränderungen seit dem Backup replizieren lassen. Wenn Sie einzelne Komponenten des Verzeichnisses wiederherstellen wollen, lesen Sie den nächsten Abschnitt.
Eine autoritative Verzeichniswiederherstellung durchführen
Da autoritative wiederhergestellte Eigenschaften höhere PVNs als die Repliken auf anderen Domänencontrollern haben, werden die Eigenschaften nach außen repliziert und überschreiben andere Repliken. Deswegen kann eine autoritative Wiederherstellung eine Menge Replikationstraffic nach sich ziehen.
Planen Sie mehrere Stunden ein und legen Sie ein besonderes Augenmerk auf Domänencontroller am anderen Ende einer langsamen WAN-Leitung. Wenn Sie bereit sind, folgen Sie der nächsten Schrittfolge:
1. Öffnen Sie eine Befehlszeile.
2. Sarten Sie Ntdsutil.
3. Geben Sie an der Eingabeaufforderung ntdsutil: den Befehl authoritative restore ein, um die gleichnamige Eingabeaufforderung aufzurufen:
|
? |
Zeigt diese Hilfeinformationen an |
|
Help |
Zeigt diese Hilfeinformationen an |
|
List NC CRs |
Listet Partitionen und Querverweise. Sie benötigen die Querverweise einer Anwendungsverzeichnispartition, um sie wiederherzustellen |
|
Quit |
Zum vorherigen Menü wechseln |
|
Restore database |
Autorisierende Wiederherstellung der gesamten Datenbank |
|
Restore database verinc %d |
... und Überschreiben der Versionserhöhung |
|
Restore object %s |
Autorisierende Wiederherstellung eines Objekts |
|
Restore object %s verinc %d |
... und Überschreiben der Versionserhöhung |
|
Restore subtree %s |
Autorisierende Wiederherstellung einer untergeordneten Struktur |
|
Restore subtree %s verinc %d |
... und Überschreiben der Versionserhöhung |
4. Wählen Sie eine Option entsprechend Ihrem Anliegen. Sie müssen den DN kennen. Angenommen, Sie wollen ein einzelnes Objekt wiederherstellen, dann könnten Sie beispielsweise Folgendes eingeben: restore object cn=fberger,ou=Berlin,dc=Firma,dc=de.
5. Ein Fenster mit der Bitte um Bestätigung wird angezeigt. Klicken Sie auf JA, um die autoritative Wiederherstellung zu starten. Die Beispielausgabe sieht wie folgt aus:
Die DIT-Datenbank wird geöffnet... Der Vorgang ist abgeschlossen.
Aktuelle Zeit 05-05-03 03:59:37.
Die letzte Datenbankaktualisierung erfolgte 05-05-03 14:27.52.
Die Versionsnummern des Attributs werden um 100000 erhöht.
Die zu aktualisierenden Datensätze werden gezählt...
Gefundene Einträge: 0000000001
Der Vorgang ist abgeschlossen.
1 Einträge wurden für die Aktualisierung gefunden.
Datensätze werden aktualisiert...
Verbleibende Datensätze: 0000000000
Der Vorgang ist abgeschlossen.
1 Datensätze wurden einwandfrei aktualisiert.
Die autorisierende Wiederherstellung wurde einwandfrei abgeschlossen.
Wird die Wiederherstellung nicht einwandfrei abgeschlossen, dann könnte die Datenbank beschädigt sein. Probieren Sie eine sanfte Wiederherstellung und eine harte Reparatur (s.u.). Versuchen Sie dann eine weitere autoritative Wiederherstellung. Klappt es dann immer noch nicht, dann stellen Sie die Daten von Band wieder her. Versuchen Sie es dann auf einem anderen Domänencontroller. Und dann können Sie langsam den Microsoft-Support anrufen.
6. Verlassen Sie nun Ntdsutil und starten Sie den Domänencontroller neu. Sobald er wieder am Netz ist, erzwingen Sie die Replikation manuell.
Fazit
Damit endet unsere fünfteilige Serie zu den Active-Directory Katastrophenszenarien. Die Artikelserie basiert auf Kapitel Zehn des Standardwerks „Windows Server 2003 für Insider“ von William Boswell aus dem Verlag Markt + Technik.
Sie können dieses über 1300 Seiten starke Buch auch in unserem Buchshop bestellen oder als eBook herunterladen.
|
Teil 1: Ausfall eines DNS-Servers und eines Domänencontrollers |
|
Teil 2: Ausfall eines FSMO-Rollenmasters |
|
Teil 4: Active Directory-Pflege |
|
Teil 5: Active Directory wiederherstellen |