Wer kennt das nicht. Man unterhält sich während der Benutzerpflege im Active Directory mit seinen Kollegen über
das gestrige Fußball-Spiel oder hängt während dessen am Telefon und versucht an einem kniffligen Problem Hilfe zu leisten,
so das man abgelenkt ist und dabei alte Benutzerkonten entfernt. Schnell wurden zwei-Klicks im Snap-In
Active Directory-Benutzer und -Computer am falschen Benutzer-Objekt getätigt und schon wurde der falsche Benutzer gelöscht.
Das ist ärgerlich. Zumal wenn es sich auch noch um das Benutzerkonto einer wichtigen Person (des CEO vielleicht?) handelt.
Oder es wird irrtümlich ein anderes Objekt gelöscht etc.
Was passiert nun genau im Hintergrund, mit dem aus Versehen gelöschten Objekt?
Welche Änderungen am Objekt während des Löschvorgangs durchgeführt werden oder welche Attribute
im Tombstone erhalten bleiben, zeigt der folgende Artikel:
Lingering Objects (veraltete Objekte)
Doch bevor das Objekt gelöscht wird und somit in den versteckten Container Deleted Objects
(in der Verzeichnispartition, in der das Objekt gelöscht wurde) wandert, wird anhand bestimmter Kriterien geprüft ob das Objekt
tatsächlich gelöscht werden darf. Diese Kriterien wären unter anderem:
Der Benutzer der das Objekt löschen möchte hat die benötigten Rechte
Das Objekt wurde nicht bereits gelöscht und somit befindet sich das Attribut Is-Deleted des Objekts, nicht auf dem gesetzten Wert True
Das System-Flags Attribut (0x80000000) des Objekts verhindert nicht das löschen
Das Objekt enthält keine untergeordneten Objekte (ansonsten erscheint eine Fehlermeldung, siehe: Computerkonto löschen)
Das Is-Critical-System Attribut des Objekts enthält nicht den Wert True
Es handelt sich nicht um ein Schemaobjekt, wie es Attribute und Klassen darstellen. Denn diese können weder
entfernt und somit auch nicht wiederhergestellt werden. Denn wenn das möglich wäre, könnten Inkonsistenzen in der
Active Directory-Datenbank (NTDS.dit) entstehen. Unter Umständen bestehen nämlich Abhängigkeiten z.B. auf das zu löschende Attribut.
Die einzige Möglichkeit wäre, dass Attribut Is-Defunct zu nutzen, um das entsprechende Attribut bzw. die Klasse zu deaktivieren
Wird nun das Objekt gelöscht, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.DIT).
Das Active Directory markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE gesetzt wird.
Dabei werden von dem Objekt die meisten Attribute auf ewig entfernt. Anschließend wandert das Objekt in den Container
Deleted Objects (der in fast allen Verzeichnispartitionen existiert) und wird ab diesem Zeitpunkt als Tombstone (zu deutsch: Grabstein) bezeichnet.
Im Container Deleted Objects erhält das Tombstone einen speziellen Relative Distinguished Name (RDN),
der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“.
Das gelöschte Objekt verbleibt in dem Container so lange, bis die Tombstone Lifetime (TSL) abgelaufen ist.
Die TSL beträgt standardmäßig bei einer ursprünglich erstellten Windows 2000 sowie Windows Server 2003 Gesamtstruktur 60 Tage.
Beim erstellen einer Gesamtstruktur mit Windows Server 2003 SP1, beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit,
wird das Objekt nun endgültig vom Garbage Collection Prozess (der alle 12 Stunden läuft) aus dem Active Directory entfernt.
Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit die Replikation genug Zeit hat,
diese Information des Löschens auch wirklich an alle DCs zu kommunizieren.
Welche Möglichkeiten hätte man nun, um das Objekt wiederherzustellen?
Zum einen funktioniert das natürlich durch eine autoritative Wiederherstellung und zum anderen bietet das Active Directory
unter Windows Server 2003 die Möglichkeit, den Tombstone, der also noch im Active Directory existiert, wiederzubeleben.
Für eine autoritative Wiederherstellung ist es ratsam, eine möglichst aktuelle System State-Sicherung des entsprechenden DCs
zu verwenden (Stichwort: Registry). Es darf keine System State-Sicherung die älter als die TSL ist, verwendet werden.
Was auch noch wichtig ist und von vielen Administratoren nicht beachtet wird, ist der Pfad zum Objekt,
also der sogenannte Distinguished-Name (DN). Dieser muss bekannt sein.
Der Nachteil bei dieser Variante der Wiederherstellung wäre, der Domänencontroller muss im Modus
„Verzeichnisdienste wiederherstellen“ gestartet werden und wäre somit für die Dauer der Wiederherstellung offline.
Der Vorteil wiederum wäre, dass z.B. ein Benutzer-Objekt mit den Einstellungen die es zum Zeitpunkt der Sicherung hatte,
wiederhergestellt wird (Stichwort: Object-GUID und Object-SID).
Einen Kern des Problems, stellen beim rücksichern von Benutzer- sowie Gruppen-Objekten, die Gruppenmitgliedschaften dar.
Dieses wird aber im folgenden KB-Artikel ausführlich behandelt. Insbesondere mit Windows Server 2003 SP1 hat sich dieses
Verhalten verbessert, was das wiederherstellen von Backlinks betrifft.
How to restore deleted user accounts and their group memberships in Active Directory
Um in den Modus Verzeichnisdienste wiederherstellen zu gelangen, gilt es beim Starten des DCs auf die F8-Taste zu drücken,
damit diese Auswahlmöglichkeit überhaupt erscheint. Erst in diesem Modus ist das Active Directory offline und kann gewartet werden.
Dort angelangt, muss zuerst das System State rückgesichert und anschließend mit NTDSUTIL das gewünschte Objekt
autoritativ wiederhergestellt werden. Denn erst mit anwenden von NTDSUTIL wird die Versionsnummer
des Objekts um 100.000 erhöht. Damit wird sichergestellt, dass zum einen das Objekt von keinem anderen DC erneut gelöscht
und zum anderen, dieses Objekt auf alle anderen DCs repliziert wird. Viele Administratoren machen an dieser Stelle oftmals einen Fehler,
denn sie starten nach dem rücksichern des System States direkt den DC im normalen Modus ohne mit
NTDSUTIL das Objekt autoritativ wiederherzustellen.
Es sei denn, es handelt sich um eine Domäne mit nur einem DC (was ohnehin grob fahrlässig wäre).
Denn dann gäbe es keinen anderen DC, der die Rücksicherung überschreiben würde und man bräuchte NTDSUTIL nicht anzuwenden.
Im Tombstone ist nämlich (unter anderem) die Object-GUID sowie Object-SID enthalten. Somit wären beim wiederbeleben
die Verweise in den ACLs der Netzwerk-Ressourcen (z.B. Freigaben etc.) weiterhin gültig und müssten nicht neu vergeben werden.
Denn beim erstellen eines Sicherheitsprinzipals (so wie es ein Benutzer-Objekt darstellt), wird auch bei der Eingabe der
gleichen Benutzerdaten wie z.B. der gleiche Benutzeranmeldename etc. eine andere Object-GUID sowie Object-SID vergeben.
Deshalb ist das neue Objekt ein „anderes“, da es sich von der GUID und SID des originalen Objekts unterscheidet.
Der Nachteil bei dieser Variante wiederum wäre, dass Objekt wird mit einigen wenigen Attributen wiederhergestellt
und die fehlenden Informationen z.B. bei einem Benutzer-Objekt, müssten erneut in den Benutzereigenschaften ein gepflegt werden.
Im Active Directory Schema ist vorgegeben, welche Attribute im Tombstone erhalten bleiben. Im Tombstone werden vor allem
keine Attribute der Gruppenzugehörigkeit oder das memberOf-Attribut eines Benutzer-Objekts gespeichert. Daher ist das
wiederbeleben eines Tombstones, zum wiederherstellen der Gruppenmitgliedschaften nicht geeignet.
Somit lässt sich im Active Directory-Schema beeinflussen, welche zusätzlichen (neben den hartcodierten) Attribute im
Tombstone erhalten bleiben. Bei der Installation eines Exchange-Servers z.B. werden zusätzliche Attribute im Tombstone gespeichert.
(den Wert auf FALSE setzen reicht in diesem Fall nicht aus) und zum anderen, muss das Distinguished-Name-Attribut vom
Objekt geändert werden. Erst jetzt ist es möglich, dass Objekt in einen anderen Container zu verschieben. Doch auch bevor das
durchgeführt werden kann, wird überprüft, ob die notwendigen Kriterien für zum durchführen dieser Aufgabe erfüllt werden.
oder LDP.exe aus den Windows Support Tools erledigen. Im Internet gibt es noch eine Menge Dritt-Anbieter Tools mit denen ein
Tombstone wiederbelebt oder das Active Directory gesichert und wiederhergestellt werden kann.
Zum speichern und wiederherstellen wichtiger Attribute, könnte auch das in Windows Server 2003 integrierte LDIFDE verwendet werden.
Als weitere Möglichkeit, kann unter Windows Server 2003 eine API verwendet werden, um einen Tombstone wiederzubeleben.
Im ersten Schritt, wird das gelöschte Objekt abgerufen und im zweiten wieder hergestellt:
Retrieving Deleted Objects (Windows)
Restoring Deleted Objects (Windows)
Beispiel:
Der DC muss zuerst im Modus “Verzeichnisdienste wiederherstellen” gestartet werden (F8 beim starten)
Nach der Anmeldung ist ein aktuelles System State z.B. mit NTBACKUP vom DC rückzusichern
Anschließend darf kein Neustart durchgeführt werden
In der Kommandozeile muss NTDSUTIL aufgerufen und folgende Befehle eingegeben werden:
authotitative restore
restore subtree <Distinguished Name der gelöschten OU>
Der Distinguished Name (DN) für eine OU Benutzer direkt unter der Domäne intra.dikmenoglu.de würde so aus:
OU=Benutzer,DC=intra,DC=dikmenoglu,DC=de
Zu guter Letzt ist durch Eingabe von „quit“ (insgesamt zweimal) das NTDSUTIL und mit „exit“ die Kommandozeile zu verlassen.
Nach einem Neustart ist die OU erneut im Active Directory verfügbar. Für eine autoritative Wiederherstellung eines Benutzer-Objekts, muss anstatt „restore subtree DN“, Weitere Informationen:
dass Kommando „restore object DN“ verwendet werden.
Wie stelle ich das AD wieder her?
Notfallwiederherstellung: Active Directory-Benutzer und -Gruppen
Useful shelf life of a system-state backup of Active Directory
How To Use the Backup Program to Back Up and Restore the System State in Windows 2000
How to perform an authoritative restore to a domain controller in Windows 2000
How to Recover from a Deleted Domain Controller Machine Account in Windows 2000
How to perform a disaster recovery restoration of Active Directory on a computer with a different hardware configuration
Das Geheimnis der Tombstone Lifetime
The effects on trusts and computer accounts when you authoritatively restore Active Directory
HOW TO: Back Up the System State Data of a Remote Computer in Windows 2000
Comments are closed, but trackbacks and pingbacks are open.