Windows Server

Tombstone-Wiederbelebung in Active Directory

Gil Kirkpatrick

Kurz zusammengefasst:

• Speicherung gelöschter Objekte in Active Directory
• Suchen und Wiederherstellen von Tombstones mittels LDP und ADRESTORE
• Objektattribute und „systemFlags“

Auch wenn es nicht zu Ihren Lieblingsthemen gehören mag: Zufällige Datenverluste passieren immer wieder, und als IT-Mitarbeiter müssen Sie auf alle möglichen Wiederherstellungsszenarios vorbereitet sein. In der Ausgabe des TechNet Magazins vom April 2007 habe ich darüber geschrieben, wie wichtig es ist, einen Plan

zum Wiederherstellen von Active Directory®-Benutzern und -Gruppen zu haben. In dem Artikel, der unter technetmagazine.com/issues/2007/04/ADRecovery verfügbar ist, habe ich die Funktionsweise von Objektverknüpfungen, Replikation, Löschen und autorisierender Wiederherstellung behandelt. Leider setzt die Funktion zur autorisierenden Wiederherstellung voraus, dass ein Domänencontroller (DC) im Verzeichnisdienst-Wiederherstellungsmodus (Directory Service Restore Mode, DSRM) gestartet wird. Dabei ist der DC für die Dauer des Wiederherstellungsvorgangs nicht verfügbar.

Es gibt aber noch einen weiteren Ansatz, den Sie kennen sollten. Das Wiederbeleben von Tombstones ist die einzige Möglichkeit zum Wiederherstellen gelöschter Objekte, bei der kein DC offline geschaltet werden muss. Und es ist die einzige Möglichkeit, die Identitätsinformationen eines gelöschten Objekts wiederherzustellen, wie z. B. seine objectGUID- und objectSid-Attribute. Damit bietet es auch eine saubere Lösung für das Neuerstellen eines gelöschten Benutzers oder einer Gruppe und das Korrigieren alter Verweise auf die Zugriffssteuerungsliste (access control list, ACL), die das objectSid-Attribut des gelöschten Objekts enthalten. Sie sollten jedoch nicht vergessen, dass die Wiederbelebung von Tombstones mit einigen Einschränkungen verbunden ist, auf die ich später näher eingehen werde. Deshalb sollten Sie die autorisierende Wiederherstellung nicht ganz aus Ihrer Trickkiste verbannen.

Die Wiederbelebung von Tombstones wurde in Windows Server® 2003 Active Directory eingeführt, um bestimmte Datenwiederherstellungsszenarios zu vereinfachen. Dieses Feature nutzt die Tatsache, dass Active Directory gelöschte Objekte für eine bestimmte Zeit in der Datenbank behält, bevor sie physisch entfernt werden. In diesem Artikel werde ich ausführlich darauf eingehen, wie mit Active Directory Objekte gelöscht und wiederbelebt werden können, und ich werde zeigen, wie Sie gelöschte Objekte mit Microsoft-Standardtools wiederherstellen können.

Was ist ein Tombstone?

Wenn Active Directory ein Objekt aus dem Verzeichnis löscht, wird es nicht sofort gänzlich aus der Datenbank entfernt. Vielmehr kennzeichnet Active Directory das Objekt als gelöscht, indem das isDeleted-Attribut des Objekts auf TRUE gesetzt und die meisten Attribute des Objekts entfernt werden. Anschließend wird das Objekt umbenannt und in einen speziellen Container im Namenskontext (naming context, NC) des Objekts mit dem Namen „CN=Deleted Objects“ verschoben. Das Objekt, das ab jetzt als Tombstone bezeichnet wird, ist nun für normale Verzeichnisvorgänge nicht mehr sichtbar. Es wird nicht in Snap-Ins der Microsoft® Management Console (MMC) angezeigt, und die meisten LDAP-Dienstprogramme (Lightweight Directory Access-Protokoll) wissen überhaupt nicht um die Existenz des Tombstones. Der Tombstone scheint nicht zu existieren. Trotzdem sind die Daten noch da – nur eben nicht sichtbar. Aber warum behält Active Directory Tombstones, also eigentlich gelöschte Objekte, in der Datenbank?

Ein Tombstone mag zwar für andere Prozesse unsichtbar sein, ist jedoch für den Replikationsvorgang in Active Directory sichtbar. Damit die Löschung auch wirklich auf allen DC durchgeführt wird, die das zu löschende Objekt hosten, repliziert Active Directory den Tombstone auf die anderen DC. Der Tombstone dient also dazu, den Löschvorgang in der Active Directory-Umgebung zu replizieren.

Gültigkeitsdauer von Tombstones

Active Directory löscht ein Objekt typischerweise als Reaktion auf einen LDAP-Protolllöschvorgang oder einen SAM-Löschvorgang (Security Account Manager) aus dem Verzeichnis. Dieser Vorgang, der auch als ursprünglicher Löschvorgang bezeichnet werden kann, ist nicht identisch mit den Löschvorgängen, die durch den Replikationsprozess von Active Directory durchgeführt werden. Dies gilt übrigens nicht für dynamische Objekte, die eine andere Löschmethode besitzen und die direkt von Active Directory gelöscht werden, wenn ihre Gültigkeitsdauer (Time to Live, TTL) abgelaufen ist.

Wenn Active Directory den Löschvorgang erhält, wird zuerst eine Prüfliste durchlaufen, um sicherzustellen, dass das Objekt gelöscht werden darf. Dieser Prozess ist vergleichsweise aufwendig, da auf diese Weise überprüft wird, dass alle folgenden Kriterien erfüllt sind:

• Das isDeleted-Attribut des Objekts ist nicht bereits auf TRUE gesetzt. (Ein bereits gelöschtes Objekt kann nicht gelöscht werden.)
• In der Sicherheitsbeschreibung des Objekts ist das ressourcenspezifische Steuerungskennzeichen „private object“, mit der das Objekt als privat gekennzeichnet wird, nicht gesetzt. (Dies scheint ein nicht dokumentiertes „Feature“ zu sein. Bei dem „private object“-Kennzeichen handelt es sich um Bit 1 des Bytes „Sbz1“ in der Struktur der Sicherheitsbeschreibung.)
• Im systemFlags-Attribut des Objekts ist das „disallow delete“-Bit (0x80000000), mit dem ein Löschen verhindert wird, nicht gesetzt.
• Das isCriticalSystemObject-Attribut des Objekts ist nicht auf TRUE gesetzt.
• In der Sicherheitsbeschreibung des Objekts werden dem Benutzer die erforderlichen Rechte zum Löschen des Objekts gewährt. (Genauer ausgedrückt: Der Benutzer ist zum Löschen des Objekts sowie zum Löschen untergeordneter Objekte berechtigt.)
• Bei dem Objekt handelt es sich nicht um ein Querverweisobjekt (objectClass = crossRef) für einen bestehenden Namenskontext.
• Das Objekt besitzt keine untergeordneten Objekte. (Wenn der LDAP-Löschvorgang die LDAP-Steuerobjekt-ID „tree delete“ zum Löschen der Struktur enthält, löscht Active Directory automatisch auch untergeordnete Objekte, sofern ihr isCriticalSystemObject-Attribut nicht auf TRUE gesetzt ist. Auf diese Weise wird verhindert, dass bei einem Strukturlöschvorgang versehentlich wichtige Systemobjekte gelöscht werden. Selbstverständlich können Sie diese Objekte jedoch einzeln löschen.)
• Das Objekt ist kein wichtiges internes Objekt (zum Beispiel nicht das nTDSDSA-Objekt für den DC oder ein Platzhalterobjekt für Vorgänger von NC-Köpfen).

Abgesehen davon, dass diese Kriterien erfüllt sein müssen, muss Active Directory auch in einem geeigneten Zustand sein, um den Löschvorgang verarbeiten zu können. Während Active Directory beispielsweise eine Domäne umbenennt, kann ein Domänenvertrauenskonto oder ein crossRef-Objekt nicht gelöscht werden.

Wenn festgestellt wird, dass das Objekt gelöscht werden kann, wandelt Active Directory das Objekt in einen Tombstone um. Active Directory entfernt zuerst unnötige Attribute des Objekts und belässt nur die in Abbildung 1 aufgeführten sowie diejenigen, die laut Schema im Tombstone verbleiben sollen. (Für weitere Informationen dazu siehe den Abschnitt „Wiederherstellen von Objektattributen“.) Anschließend wird der RDN (Relative Distinguished Name) des Objekts in CN=<old RDN>\0ADEL:<objectGUID> geändert, wobei \0A für das ASCII-Zeilenvorschubzeichen steht und <objectGUID> für das objectGUID­Attribut als Zeichenfolge. Das lastKnownParent-Attribut wird dann auf den DN (Distinguished Name) des übergeordneten Containers des Objekts gesetzt, und das isDeleted-Attribut wird auf TRUE gesetzt. Active Directory entfernt dann alle Forwardlink- und Backwardlinkattribute des Objekts. Sofern das „disallow move on delete“-Bit des systemFlag-Attributs des Objekts, das ein Verschieben beim Löschen verhindert, nicht gesetzt ist, verschiebt Active Directory das Objekt schließlich in den Container „CN=Deleted Objects“ für den NC. (Zu weiteren Informationen zu diesem Thema siehe die Randleiste „systemFlags-Attribut und Objektverhalten“.)

Figure 1 In einem Tombstone gespeicherte Attribute

Beachten Sie, dass der Ordner „CN=Deleted Objects“ flach ist und keine Objekthierarchie besitzt. Das lässt zunächst vermuten, dass es beim Löschen von zwei verschiedenen Objekten mit demselben CN zu Namenskonflikten kommen wird. Dies ist jedoch nicht der Fall. Da der RDN eines Tombstones das objectGUID-Attribut enthält, ist der RDN jedes Tombstones innerhalb des Containers „CN=Deleted Objects“ einmalig.

Natürlich verbleiben die Objekte nicht für immer im Container „CN=Deleted Objects“. Die Standardgültigkeitsdauer eines Tombstones beträgt für ursprünglich mit Windows® 2000 und Windows Server 2003 erstellte Gesamtstrukturen 60 Tage und für ursprünglich mit Windows Server 2003 SP1 erstellte Gesamtstrukturen 180 Tage. Sie können die Gültigkeitsdauer eines Tombstones mithilfe des tombstoneLifetime-Attributs des Objekts „CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Stammdomäne>“ verändern.

Jeder Domänencontroller startet alle 12 Stunden eine Garbage Collection. (Um diesen Zeitraum zu ändern, kann das garbageCollPeriod-Attribut des Objekts „CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<Stammdomäne>“ auf einen neuen Wert gesetzt werden.) Bei der Garbage Collection werden alle Tombstones des DC gescannt und alle diejenigen physisch gelöscht, bei denen die Tombstonegültigkeitsdauer überschritten ist.

Einsatz von LDP zum Suchen von Tombstones

LDP ist ein Dienstprogramm für die Arbeit mit Active Directory, das Windows Explorer ähnelt. LDP wurde ursprünglich vom Active Directory-Entwicklungsteam entworfen, um während der Entwicklung von Active Directory den LDAP-Code testen zu können. Inzwischen gehört LDP zu den Supporttools für Windows Server 2003 und hat sich zu einem robusten Werkzeug für die Arbeit mit Active Directory entwickelt.

Obwohl Tombstones für normale Verzeichnisvorgänge nicht sichtbar sind, können Sie Tombstoneobjekte in Active Directory mit LDAP-Suchvorgängen und besonderen LDAP-Erweiterungen, so genannten Steuerelemente, suchen. Bei den Steuerelementen handelt es sich um eine im LDAP-Standard definierte Methode zum Erweitern des LDAP-Protokolls, um zusätzliche Funktionalität über den LDAP-Standard hinaus bereitzustellen, ohne dass die Kompatibilität mit sonstiger LDAP-konformer Software beeinträchtigt wird. Active Directory unterstützt 22 Steuerelemente, darunter auch das Return Deleted Objects-Steuerelement zum Zurückgeben gelöschter Objekte. Wenn dieses Steuerelement zum Erweitern eines LDAP-Suchvorgangs verwendet wird, ruft es gelöschte Objekte ab, die andernfalls nicht sichtbar wären.

Um dieses Prinzip zu demonstrieren, melde ich mich in der Domäne „foo.local“ als Organisationsadministrator an und verwende dann das MMC-Snap-In „Active Directory-Benutzer und -Computer“ (Active Directory Users and Computers, ADUC), um wie in Abbildung 2 gezeigt ein Benutzerobjekt zu erstellen (CN=John Smith,CN=Users,DC=foo, DC=local). Dann lösche ich das Benutzerobjekt wieder, ebenfalls mit ADUC.

Abbildung 2** Benutzerkontoerstellung mit ADUC **(Klicken Sie zum Vergrößern auf das Bild)

Jetzt kann ich das LDP-Programm ausführen und damit den Tombstone des gelöschten Benutzerkontos anzeigen. Der erste Schritt besteht darin, LDP mit einem bestimmten DC zu verbinden und mit den entsprechenden Anmeldeinformationen eine Authentifizierung durchzuführen. Um die Verbindung zum DC herzustellen, wähle ich einfach im Menü „Connection“ (Verbindung) die Option „Connect“ (Verbindung herstellen). Da ich LDP auf dem DC ausführe, wähle ich nun einfach „OK“, um die Verbindung zum lokalen DC herzustellen. Wenn Sie LDP von einem Remotestandort aus ausführen, müssen Sie den Namen des DC angeben, mit dem die Verbindung hergestellt werden soll. Nachdem die Verbindung auf diese Weise hergestellt wurde, zeigt LDP die Attribute von „rootDSE“ an. Dies sind Attribute, die den Zustand und die Konfiguration des DCs selbst beschrieben (siehe Abbildung 3).

Abbildung 3** LDP mit DC verbunden **(Klicken Sie zum Vergrößern auf das Bild)

Um nun die Authentifizierung gegenüber dem DC als Domänen- oder Organisationsadministrator durchzuführen, wähle ich im Menü „Connection“ die Option „Bind“ (Binden). Da ich bereits als Organisationsadministrator für die Gesamtstruktur angemeldet bin (Domänen- und Organisationsadministratoren sind standardmäßig zum Auflisten und Wiederbeleben von Objekten im Container „CN=Deleted Objects“ berechtigt), lasse ich einfach die Felder zur Eingabe von Benutzernamen und Kennwort im Dialogfeld „Bind“ leer und klicke auf „OK“. Andernfalls könnte ich die entsprechenden Anmeldeinformationen hier eingeben.

Nun möchte ich den Inhalt des Containers „CN=Deleted Objects,DC=foo,DC=local“ auflisten. Normalerweise ist der Container „CN=Deleted Objects“ nicht sichtbar, weil er selbst als gelöscht gekennzeichnet ist. Die einzige Möglichkeit, den Container „CN=Deleted Objects“ zu suchen, bietet das LDAP-Steuerelement„Return Deleted Objects“ zum Zurückgeben gelöschter Objekte.

Um LDP mit diesem Steuerelement zu verwenden, wählen Sie im Menü „Browse“ (Durchsuchen) die Option „Search“ (Suchen). Das Suchdialogfeld (siehe Abbildung 4) wird angezeigt. Im Feld „Base Dn“ (Basis-DN) können Sie angeben, wo in der Verzeichnisstruktur die Suche beginnen soll. Ich gebe daher die DN des Containers „Deleted Objects“ für die Domäne ein, in diesem Beispiel also „CN=Deleted Objects,DC=foo,DC=local“.

Abbildung 4** LDP-Suchdialogfeld **

Im Feld „Filter“ gebe ich die gewünschten Suchkriterien ein. Der Standardwert ist (objectClass=*), wodurch die Suche angewiesen wird, alle Objekte zurückzugeben, deren objectClass-Attribut einen Wert hat. Weil in Active Directory sogar gelöschte Objekte einen Wert für „objectClass“ besitzen, findet der Standardfilter alle Objekte innerhalb des Suchbereichs. In diesem Beispiel ändere ich den Filter in (objectClass=user), um die Suche auf Benutzerobjekte einzuschränken. Dies erleichtert die Suche nach dem gelöschten Benutzer John Smith unter den vielleicht Tausenden von Tombstones im Container „CN=Deleted Objects“.

Möglicherweise enthält der Container „CN=Deleted Objects“ mehr Objekte, als Active Directory in einem einzigen Suchvorgang zurückgeben kann. Um dieses Problem zu umgehen, könnten Sie die LDAP-Suche beispielsweise seitenweise durchführen, sodass die Ergebnisse in Gruppen aufgeführt werden. In LDP ist es jedoch nicht möglich, eine Seitensuche mit einer erweiterten Suche zu kombinieren. Daher müssen Sie Ihren LDAP-Filter verfeinern, um das gewünschte Objekt zu finden.

Mit den Optionsfeldern unter „Scope“ (Bereich) können Sie angeben, welcher Teil der Verzeichnisstruktur durchsucht werden soll. Bei einer Basissuche wird nur das Objekt zurückgegeben, das im Feld „Base Dn“ angegeben ist. Bei einer Suche in einer einzigen Ebene werden die Objekte zurückgegeben, die dem „Base dn“-Objekt direkt untergeordnet sind. Beim Durchsuchen einer Unterstruktur werden alle Objekte zurückgegeben, die dem „Base Dn“-Objekt untergeordnet sind. Weil der Ordner „CN=Deleted Objects“ flach ist, verwende ich zum Abrufen aller Tombstones eine Suche über eine Ebene.

Bis jetzt habe ich im Wesentlichen eine konventionelle LDAP-Suche skizziert. Wenn ich diese jetzt ausführen würde, würde LDP einen Fehler anzeigen mit dem Hinweis, dass „CN=Deleted Objects,DC=foo,DC=com“ nicht existiert, weil es als gelöscht gekennzeichnet ist. Ich muss nämlich noch das LDAP-Steuerelement „Return Deleted Objects“ zum Zurückgeben gelöschter Objekte in den Suchvorgang einbinden. Dazu klicke ich im Dialogfeld „Search“ auf die Schaltfläche „Options“ (Optionen) und wähle als „Call Type“ (Aufruftyp) für die Suche die Option „Extended“ (Erweitert) (siehe Abbildung 5). Diese Option ermöglicht es mir, für den Suchvorgang Steuerelemente anzugeben. Hier ändere ich auch die Liste „Attribute“ in *. Dadurch zeigt LDP anstelle des LDP-Standardattributsatzes für jedes abgerufene Objekt alle normalen Attribute an.

Abbildung 5** LDP-Dialogfeld „Search Options“ (Suchoptionen) **

Nun öffne ich über die Schaltfläche „Controls“ (Steuerelemente) das gleichnamige Dialogfeld. Das Dialogfeld ist nicht ganz einfach. Befolgen Sie daher unbedingt genau die nachfolgend aufgeführten Schritte, um das Steuerelement „Return Deleted Objects“ zum Zurückgeben gelöschter Objekte hinzuzufügen.

Öffnen Sie die Dropdownliste „Load Predefined“ (Vordefinierte laden), wählen Sie „Return Deleted Objects“ (Gelöschte Objekte zurückgeben), und klicken Sie auf die Schaltfläche „Check in“ (Einchecken). Dadurch wird die Objektkennung (object identifier, OID) für das Steuerelement „Return Deleted Objects“ zum Zurückgeben gelöschter Objekte (1.2.840.113556.1.4.417) in die Liste „Active Controls“ (Aktive Steuerelemente) eingefügt (siehe Abbildung 6). LDP fügt dieses Steuerelement dann in alle folgenden erweiterten Suchvorgänge ein. Klicken Sie auf „OK“, um die Einstellungen zu speichern, und dann erneut auf „OK“, um das Dialogfeld „Search Options“ zu schließen.

Abbildung 6** Hinzufügen des Steuerelements „Return Deleted Objects“ **

Das Dialogfeld „Controls“ weist in bestimmten Fällen ein eigentümliches Verhalten auf. Besonders ist hier die Tatsache zu nennen, dass, auch wenn ein OID in der Liste „Active Controls“ angezeigt wird, dieses Steuerelement nicht zwangsläufig auch angewendet wird. Manchmal müssen Sie ein Steuerelement aus- und dann wieder einchecken, um sicherzustellen, dass es beim nächsten LDAP-Vorgang verwendet wird.

Meine Suche ist nun also zum Ausführen bereit. Daher klicke ich im LDP-Suchdialogfeld auf die Schaltfläche „OK“. LDP ruft dann für die Domäne sämtliche Benutzerobjekte aus dem Container „CN=Deleted Objects“ ab. Das Ergebnis meiner Suche sehen Sie in Abbildung 7.

Abbildung 7** Suchergebnis aus dem Container „CN=Deleted Objects“ **(Klicken Sie zum Vergrößern auf das Bild)

Prüfung des LDP-Ergebnisses

Meine Suche hat zwei Tombstoneobjekte zurückgegeben. Zunächst sehen Sie hier den DN des ersten Tombstones: CN=John Smith\0ADEL:41800281-6bc4-42c3-a99b-b283022b3af8,CN=Deleted Objects,DC=foo,DC=local. Die objectGUID des gelöschten Objekts wird als Zeichenfolge dargestellt (41800281-6bc4-42c3-a99b-b283022b3af8). Unter dem DN befindet sich eine Attributliste mit Werten für „objectClass“, „cn“, „distinguishedName“ usw. Wie Sie sehen, hat das isDeleted-Attribut den Wert TRUE. Das Objekt wurde also tatsächlich gelöscht. Außerdem sehen Sie, dass die „objectSid“ im Tombstone erhalten geblieben ist. Dies wird beim Wiederherstellen von Benutzer- und Gruppentombstones wichtig, wie ich später zeigen werde. Das lastKnownParent-Attribut, das den DN des Objekts angibt, in dem das gelöschte Objekt enthalten war, bevor es zu einem Tombstone wurde, spielt beim Wiederherstellen von Tombstones ebenfalls eine wichtige Rolle.

In meinem Beispiel zeigt LDP zwei Tombstoneobjekte an, beides Benutzerobjekte mit dem Namen „CN=John Smith“, die ursprünglich aus dem Container „CN=Users,dc=foo,dc=local“ stammen. Wie kann es zwei verschiedene Objekte mit dem gleichen RDN aus demselben Container geben? Die Erklärung ist ziemlich einfach. Bevor ich LDP zum Suchen von Tombstones ausgeführt habe, habe ich das Benutzerobjekt „CN=John Smith“ im Container „CN=Users,DC=foo,DC=local“ erstellt und dann gelöscht. Dann habe ich ein zweites Benutzerobjekt mit den gleichen Attributen erstellt und ebenfalls gelöscht. Weil ich das erste Benutzerobjekt „CN=John Smith“ bereits gelöscht hatte, war es durchaus sinnvoll, das zweite zu erstellen, auch wenn es den gleichen Namen hatte. Dennoch sind dies unabhängige, einmalige Objekte, die sich anhand ihrer jeweiligen „objectGUID“ unterscheiden lassen. Weil Active Directory die „objectGUID“ in den DN des Tombstones integriert, werden sie im Container „CN=Deleted Objects“ als separate Objekte angezeigt.

Wiederbeleben von Tombstones

Active Directory verfügt über eine Methode, mit der sich Tombstones wieder in normale Objekte verwandeln lassen. Im Prinzip wird damit das Löschen eines Objekts wieder aufgehoben. Bei dieser Funktion handelt es sich um eine speziell gebildete LDAP-Operation, die zwei ganz bestimmte Attributänderungen umfassen muss: Einerseits muss das isDeleted-Attribut entfernt (und nicht nur auf FALSE gesetzt) werden, und andererseits muss das Objekt durch Ändern seines distinguishedName-Attributs in einen anderen Container verschoben werden. Der neue DN verwendet typischerweise (aber nicht zwangsläufig) das lastKnownParent-Attribut als Container und behält den bisherigen RDN ohne die Komponente „\0ADEL:<: objectGUID>“, die Active Directory beim Erstellen des Tombstones hinzugefügt hat.

Vor dem Wiederbeleben des Tombstones überprüft Active Directory, dass bestimmte notwendige Bedingungen erfüllt sind. Der Benutzer muss über das erweiterte Zugriffsrecht zum Wiederbeleben von Tombstones verfügen, das im NC-Kopf des NC definiert ist, das den Tombstone enthält. Der Benutzer kann nicht sein eigenes Objekt wiederbeleben. Das isDeleted-Attribut des Tombstones muss auf TRUE gesetzt sein. Die Besitzer-Sicherheits-ID (SID) des Objekts, wie in der Sicherheitsbeschreibung definiert, muss eine SID aus einer der Domänen in der Gesamtstruktur oder einer vertrauenswürdigen Domäne haben.

Wenn sich das betreffende Objekt in den Konfigurations- oder Schema-NCs befindet, müssen die Bits FLAG_CONFIG_ALLOW_RENAME und FLAG_ CONFIG_ALLOW_MOVE im systemFlags-Attribut des Tombstones gesetzt sein. Wenn sich das Objekt in den Konfigurations- oder Schema-NCs befindet und das Kennzeichen FLAG_CONFIG_ALLOW_LIMITED_MOVE gesetzt ist, kann das Objekt nur in einen Container verschoben werden, der dasselbe übergeordnete Objekt zweiter Ebene besitzt. Anders ausgedrückt: Das Objekt muss nach dem Verschieben dasselbe übergeordnete Objekt dritter Ebene haben wie zuvor. Wenn sich das Objekt in einem Domänen-NC oder einer Anwendungspartition befindet, dürfen außerdem die Bits FLAG_DOMAIN_DISALLOW_RENAME und FLAG_DOMAIN_DISALLOW_MOVE im systemFlags-Attribut des Tombstones nicht gesetzt sein.

Der Benutzer muss wie in der Sicherheitsbeschreibung definiert berechtigt sein, den RDN (meist, aber nicht immer = CN) zu ändern und das Objekt dem neuen übergeordneten Container hinzuzufügen. Außerdem muss der neue übergeordnete Container ein mögliches übergeordnetes Element für die „objectClass“ des Tombstones sein, wie im Schema definiert. Obwohl ein Verschieben in oder aus dem Systemcontainer normalerweise nicht zulässig ist (außer wenn der Registrierungswert „Unlock“ der Systemunterstruktur ungleich null ist), ist das Wiederbeleben eines Tombstones in den Systemcontainer möglich.

Das Wiederbeleben eines Schemaobjekts ist niemals zulässig. Dies ist jedoch normalerweise kein Problem, da ein Objekt ohnehin nicht aus dem Schema-NC gelöscht werden darf.

Wenn alle Überprüfungen erfolgreich durchgeführt wurden und die notwendigen Voraussetzungen erfüllt sind, führt Active Directory mit dem Tombstone folgende Schritte durch, um das Objekt wiederzubeleben:

• Das isDeleted-Attribut wird entfernt.
• Sofern im Änderungsvorgang nicht anders angegeben, wird „objectCategory“ auf die spezifischste „objectClass“ gesetzt, die im Tombstone angegeben ist.
• Der RDN wird geändert, und das Objekt wird in den neuen übergeordneten Container geschrieben.

Nach dem Wiederbeleben hat das Objekt die gleichen objectGUID- und objectSid-Attribute wie vor dem Löschen. Das bedeutet, dass externe Verweise auf das Objekt, beispielsweise in Zugriffssteuerungslisten, nicht zurückgesetzt werden müssen, wie es beim Wiederherstellen eines gelöschten Objekts der Fall ist. Aussehen und Verhalten des wiederbelebten Objekts sind ebenso wie vor dem Löschen. Es besteht jedoch ein wichtiger Unterschied: Dem wiederhergestellten Objekt fehlen sämtliche Attribute, die nicht im Tombstone gespeichert wurden.

Verwenden von LDP zum Wiederbeleben von Tombstones

systemFlags-Attribut und Objektverhalten

Das systemFlags-Attribut ist ein optionales Attribut, das für die Klasse „Top“ definiert wurde und das „systemFlags“ zu einem optionalen Attribut für jede Active Directory-Klasse macht. Es handelt sich dabei um eine 32-Bit-Ganzzahlmaske, die das Verhalten beim Verschieben und Löschen von Objekten steuert. Wichtige Kennzeichen:

FLAG_DISALLOW_DELETE (0x80000000)

Wenn dieses Kennzeichen gesetzt ist, lässt das System das Löschen oder Verschieben des Objekts in eine andere Domäne nicht zu.

FLAG_CONFIG_ALLOW_RENAME (0x40000000)

Objekte in den Konfigurations- und Schema-NCs können nicht umbenannt werden, wenn dieses Kennzeichen im systemFlags-Attribut nicht gesetzt ist.

FLAG_CONFIG_ALLOW_MOVE (0x20000000)

Objekte in den Konfigurations- und Schema-NCs können nicht verschoben werden, wenn dieses Kennzeichen im systemFlags-Attribut nicht gesetzt ist.

FLAG_CONFIG_ALLOW_LIMITED_MOVE (0x10000000)

Objekte in den Konfigurations- und Schema-NCs können nicht verschoben werden, wenn dieses Kennzeichen im systemFlags-Attribut nicht gesetzt ist. Dieses Kennzeichen legt eine weitere Beschränkung für den Zielcontainer des Verschiebevorgangs fest: Der Zielcontainer muss dasselbe übergeordnete Element zweiter Ebene haben wie der aktuelle Container.

FLAG_DOMAIN_DISALLOW_RENAME (0x08000000)

Standardmäßig können Objekte in einem Domänen-NC oder Anwendungs-NC umbenannt werden. Wenn dieses Kennzeichen jedoch im systemFlags-Attribut des Objekts gesetzt ist, lässt das System ein Umbenennen des Objekts nicht zu.

FLAG_DOMAIN_DISALLOW_MOVE (0x04000000)

Standardmäßig können Objekte in einem Domänen-NC oder Anwendungs-NC in einen anderen Container verschoben werden. Wenn dieses Kennzeichen jedoch im systemFlags-Attribut des Objekts gesetzt ist, lässt das System ein Verschieben des Objekts nicht zu.

FLAG_DISALLOW_MOVE_ON_DELETE (0x02000000)

Wenn dieses Kennzeichen gesetzt ist, verschiebt das System das Objekt nicht in den Container „CN=Deleted Objects“ seines Namenskontexts. Stattdessen werden das isDeleted-Attribut gesetzt, das Objekt umbenannt und die Attribute entfernt, die nicht im Schema als zu speichernde Attribute festgelegt sind. Das bedeutet, dass nicht alle gelöschten Objekte im Container „CN=Deleted Objects“ für den Namenskontext angezeigt werden; einige verbleiben im ursprünglichen übergeordneten Container.

Nachdem Sie jetzt das Prinzip der Wiederbelebung von Tombstones kennen, möchte ich Ihnen zeigen, wie ich mit LDP den gelöschten Benutzer „CN=John Smith“ wiederherstellen kann. Zunächst stelle ich eine Verbindung zu einem DC her und führe die Authentifizierung durch. Jetzt kann ich mit LDP einen Änderungsvorgang durchführen. In den Parametern des Änderungsvorgangs kann ich das isDeleted-Attribut entfernen und gleichzeitig einen neuen DN angeben.

Weil ich diese Vorgänge an einem Tombstone durchführe, muss ich das LDAP-Steuerelement„Return Deleted Objects“ zum Zurückgeben gelöschter Objekte verwenden. Um dieses Steuerelement für den Änderungsvorgang in LDP festzulegen, wähle ich zunächst im Optionsmenü „Controls“ (Steuerelemente). Dann wähle ich in der Dropdownliste „Load Predefined“ (Vordefinierte laden) die Option „Return Deleted Objects“ (Gelöschte Objekte zurückgeben) und klicke auf die Schaltfläche „Check in“ (Einchecken). Anschließend wähle ich „OK“, um die Einstellungen zu speichern.

Dann wähle ich im Menü „Browse“ (Durchsuchen) die Option „Modify“ (Ändern), um das gleichnamige Dialogfeld zu öffnen und den DN des Tombstoneobjekts einzugeben, das ich wiederherstellen will. Am einfachsten geht das durch Kopieren und Einfügen des DNs aus den Ergebnissen des zuvor durchgeführten Suchvorgangs.

Nun muss ich noch eine Liste von Attributvorgängen eingeben, die durchgeführt werden sollen. Zum Wiederbeleben eines Tombstones sind zwei Attributvorgänge erforderlich: das isDeleted-Attribut muss gelöscht werden, und das distinguishedName-Attribut muss durch den DN des wiederbelebten Tombstones ersetzt werden. Also gebe ich „isDeleted“ in das Feld „Attribute“ (Attribut) ein und aktiviere das Optionsfeld „Delete“ (Löschen). Wenn ich nun die Eingabetaste drücke, wird der Attributvorgang in die Eintragsliste eingefügt (siehe Abbildung 8).

Abbildung 8** Angabe von Attributvorgängen **

Anschließend gebe ich in das Feld „Attribute“ den Wert „distinguishedName“ ein, aktiviere das Optionsfeld „Replace“ (Ersetzen) und gebe den neuen DN des Objekts in das Feld „Values“ (Werte) ein. In diesem Fall verwende ich den ursprünglichen „distuiguishedName“ des Benutzers: „CN=John Smith,CN=Users,DC=foo,DC=local“. Wenn ich nun die Eingabetaste drücke, wird der Attributvorgang in die Eintragsliste eingefügt.

Weil ich das LDAP-Steuerelement „Return Deleted Objects“ zum Zurückgeben gelöschter Objekte in den Änderungsvorgang einbeziehen muss, muss ich eine erweiterte LDAP-Änderung verwenden. Dazu aktiviere ich das Kontrollkästchen „Extended“ (Erweitert). Wenn alles wie in Abbildung 9 gezeigt eingegeben ist, klicke ich zum Übernehmen der Änderungen auf die Schaltfläche „Run“ (Ausführen). LDP zeigt die Ergebnisse in einem großen Textfenster an.

Abbildung 9** Ändern des distinguishedName-Attributs **

Wenn ich nun wieder zum MMC-Snap-In „Active Directory-Benutzer und -Computer“ wechsele und den Container „CN=Users“ betrachte, ist das vormals gelöschte Benutzerobjekt wieder an seinem ursprünglichen Platz. Jedoch unterscheidet sich das Objekt in einigen wesentlichen Punkten von seinem ursprünglichen Zustand. Mehr dazu gleich.

Wiederbeleben von Tombstones mittels ADRESTORE

Wenn Sie einmal die Verwendung von LDP verstanden haben, ist das Wiederbeleben eines Tombstones eigentlich nicht weiter schwierig. Besonders einfach ist es andererseits auch wieder nicht. Glücklicherweise hat das Team von Sysinternals (einem Unternehmen, das inzwischen zu Microsoft gehört), ein Befehlszeilenprogramm entwickelt, um diesen Wiederbelebungsprozess zu vereinfachen. Dieses Tool mit dem Namen ADRESTORE ist auf der Microsoft-Website unter microsoft.com/technet/sysinternals/utilities/AdRestore.mspx verfügbar. Die Installation ist ganz einfach. Kopieren Sie einfach die EXE-Datei in ein geeignetes Verzeichnis auf Ihrem Computer, zum Beispiel das Verzeichnis C:\WINDOWS\SYSTEM32.

ADRESTORE kann in zwei Modi ausgeführt werden. Wenn Sie es ohne Parameter ausführen, listet es sämtliche Tombstones im Container „CN=Deleted Objects“ der Standarddomäne auf. Sie können eine Suchzeichenfolge in die Befehlszeile einfügen, um die anzuzeigenden Objekte auszuwählen. Beispiel:

C:\> adrestore John

Auf diese Weise werden alle Tombstoneobjekte im Container „CN=Deleted Objects“ angezeigt, die in ihrem CN- oder OU-Attribut die Zeichenfolge „John“ enthalten. Verwendet werden die LDAP-Suchfilter „cn=*John*“ und „ou=*John*“. Dies mag zwar nicht die flexibelste Vorgehensweise zum Suchen von Tombstoneobjekten sein, aber sie funktioniert in den meisten Fällen. Abbildung 10 zeigt das Ergebnis meiner Suche in ADRESTORE.

Abbildung 10** In einem Tombstone gespeicherte Attribute **(Klicken Sie zum Vergrößern auf das Bild)

Wenn Sie einen Tombstone nicht nur suchen sondern auch wiederbeleben wollen, müssen Sie den Schalter –r zusammen mit einer optionalen Zeichenfolge verwenden, wie z. B. im folgenden Beispiel:

C:\> adrestore –r John

Mit diesem Befehl werden Sie zum Wiederbeleben jedes passenden Tombstoneobjekts aufgefordert. ADRESTORE platziert das wiederbelebte Objekt immer in dem Container, der mit dem lastKnownParent-Attribut des Tombstones angegeben ist. Es gibt keine Möglichkeit, einen anderen Container anzugeben.

ADRESTORE ist eine praktische Befehlszeilenschnittstelle zum Verwenden der Wiederbelebungsfunktionen in Active Directory. Auch wenn sie nicht übermäßig flexibel ist, so ist sie doch einfacher zu verwenden als LDP. Dennoch lassen sich auch mit ADRESTORE zwei zentrale Probleme beim Wiederbeleben von Tombstones nicht umgehen: Die Wiederherstellung der Attribute, die beim Löschen des Objekts entfernt wurden, und die Wiederherstellung von Objekten, die aus dem Konfigurations-NC gelöscht wurden.

Wiederherstellen von Objektattributen

In Sachen Datenwiederherstellung hat die Wiederbelebung von Tombstones gegenüber einer autorisierenden Wiederherstellung einen großen Vorteil: Bei der Wiederbelebung von Tombstones muss der DC nicht offline geschaltet werden. Außerdem hat die Wiederbelebung von Tombstones gegenüber dem Erstellen einer neuen Version eines gelöschten Objekts einige Vorteile. Wenn Sie ein Objekt neu erstellen, erhält es immer neue objectGUID- und objectSid-Attribute (wenn es sich um einen Sicherheitsprinzipal wie z. B. einen Benutzer handelt). Folglich müssen sämtliche externen Verweise auf das Objekt, wie z. B. ACLs, mit der Identität des neuen Objekts aktualisiert werden. Das kann ein echtes Problem sein.

Einige Attribute werden beim Löschen eines Objekts entfernt, und diese Attribute können bei der Wiederbelebung eines Tombstones nicht wiederhergestellt werden. Active Directory speichert allerdings einige Hauptattribute im Tombstone. Zu den Wichtigsten zählen hier identitätsbezogene Attribute wie z. B. „objectGUID“ und „objectSid“. Auch viele andere Attribute werden standardmäßig gespeichert (siehe Abbildung 1). Die meisten Attribute, die hartcodiert gespeichert werden, sind nur mäßig interessant, insbesondere wenn es um das Wiederherstellen von gelöschten Benutzerobjekten geht. Sie können jedoch über Bit 3 (0x00000008) des searchFlags-Attributs des entsprechenden attributeSchema-Objekts im Active Directory-Schema festlegen, welche zusätzlichen Attribute im Tombstone gespeichert werden sollen. Für einige Attribute ist dieses Bit in Windows Server 2003 R2 bereits im Schema gesetzt (siehe Abbildung 1).

Bei der Installation bestimmter Anwendungen kann es vorkommen, dass Bit 3 der „searchFlags“ vorhandener Attribute geändert wird oder dass sogar neue Attribute hinzugefügt werden, bei denen Bit 3 gesetzt ist. Exchange Server konfiguriert beispielsweise mehrere zusätzliche Attribute so, dass diese im Tombstone gespeichert werden.

Active Directory speichert keine Forwardlink- oder Backwardlinkattribute im Tombstone, selbst wenn Sie dies im searchFlags-Attribut des Schemaobjekts angegeben haben. Insbesondere speichert Active Directory beispielsweise nicht die Mitgliedsattribute einer Gruppe oder das memberOf-Attribut eines Benutzers. Daher ist die Wiederbelebung von Tombstones keine Lösung für das Wiederherstellen von Gruppenmitgliedschaften in Active Directory. Siehe dazu auch meinen Artikel „Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen“ unter technetmagazine.com/issues/2007/04/ADRecovery. Sie benötigen also auch weiterhin eine alternative Methode zum Wiederherstellen dieser Informationen beim Wiederbeleben von Tombstones.

Wenn Sie die Wiederbelebung von Tombstones im Rahmen Ihrer Strategie zur Datenwiederherstellung einsetzen möchten, müssen Sie entweder sicherstellen, dass die wichtigen Attribute im Tombstone gespeichert werden, oder Sie benötigen eine andere Möglichkeit zum Speichern und Wiederherstellen wichtiger Attribute, etwa durch die Verwendung von LDIFDE oder eines anderen Sicherungs- und Wiederherstellungsschemas. Weitere Optionen sind Active Directory-Datenwiederherstellungsprogramme von Drittanbietern, die eine automatisierte Methode zum Sichern und Wiederherstellen von Attributen bieten, die nicht im Tombstone gespeichert werden und anders wiederhergestellt werden müssen.

Wiederbeleben von Objekten aus dem Konfigurationsnamenskontext

Eine weitere wesentliche Beschränkung der Tombstonewiederbelebung besteht darin, dass im Allgemeinen keine Objekte wiederbelebt werden können, die aus dem Konfigurations-NC gelöscht wurden. Die Objekte unterliegen in Bezug auf Verschieben und Umbenennen besonderen, über das systemFlags-Attribut des Objekts definierten Regeln. Sofern dieses keine anders lautende Vorgabe enthält, können Objekte im Konfigurations-NC nicht verschoben oder umbenannt werden. Das bedeutet, dass ihre Tombstones nicht wiederbelebt werden können. Active Directory erzwingt beim Erstellen von Objekten bestimmter Klassen bestimmte Werte für das systemFlags-Attribut (siehe Abbildung 11). Beachten Sie, dass Active Directory die bitweise logische OR-Operation auf diese Werte in Verbindung mit allen systemFlags-Werten anwendet, die beim Hinzufügen angegeben wurden. Das bedeutet, dass die entsprechenden Bits richtig gesetzt werden, auch wenn die Anwendung einen anderen Wert für das systemFlags-Attribut angibt.

Figure 11 systemFlags-Standardeinstellungen

Die einzigen Objekte aus dem Konfigurations-NC, die Sie im Normalfall wiederbeleben können, sind Serverobjekte. Wenn Active Directory ein Serverobjekt löscht, wird der Tombstone interessanterweise nicht in den Container „CN=Deleted Objects“ für den Konfigurations-NC verschoben, sondern verbleibt an derselben Stelle wie das Objekt. Dies ermöglicht dem für das Berechnen der Active Directory-Replikationstopologie verantwortlichen Prozess, Knowledge Consistency Checker (KCC), die automatische Wiederherstellung bei bestimmten Szenarios, in denen gelöschte Serverobjekte eine fehlerfreie Replikation verhindern könnten. Wenn Sie also versuchen ein Serverobjekt wiederzubeleben, denken Sie daran, dass es sich nicht im Container „CN=Deleted Objects“ befindet.

Wiederbeleben im Rahmen eines Wiederherstellungsplans

Das Wiederbeleben von Tombstones sollte zentraler Bestandteil Ihres Toolkits zur Datenwiederherstellung sein. Diese Methode ist die einzige Möglichkeit zum Wiederherstellen gelöschter Objekte ohne einen DC offline zu schalten. Es ist, was ebenso wichtig ist, die einzige Möglichkeit, die Identitätsinformationen eines gelöschten Objekts wiederherzustellen. Damit bietet es zugleich eine saubere Lösung für das Neuerstellen eines gelöschten Benutzers oder einer Gruppe und das Korrigieren sämtlicher alter Verweise auf die Zugriffssteuerungsliste.

Doch das Wiederbeleben von Tombstones ist eine unvollständige Lösung. Sie benötigen zusätzlich eine eigene Methode zum Wiederherstellen der Attribute, die Active Directory nicht in Tombstoneobjekten behält. Zudem sind die Möglichkeiten zum Wiederherstellen gelöschter Objekte aus dem Konfigurations-NC begrenzt. Wenn Sie einen gelöschten Benutzer oder eine Gruppe wiederbeleben, müssen Sie Gruppenmitgliedschaften und sämtliche anderen, ggf. benötigten verknüpften Attribute auf andere Weise wiederherstellen.

Gil Kirkpatrick ist CTO von NetPro und entwickelt seit 1996 Software für Active Directory. Zusammen mit Guido Grillenmeier von HP bietet er die beliebten Workshops zur Active Directory-Notfallwiederherstellung an. Gil ist darüber hinaus Gründer der Directory Experts Conference (www.dec2007.com).

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.