Wenn im Active Directory (AD) Objekte gelöscht werden, verschwinden diese nicht sofort aus der AD-Datenbank (NTDS.dit). Das AD markiert das Objekt als gelöscht, indem das Attribut Is-Deleted des Objekts auf den Wert TRUE (Wahr) gesetzt wird. Dabei werden von dem Objekt die meisten Attribute für immer 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 Distinguished Name (DN), der so aussieht: „CN=<alter RDN>\0ADEL:<Object-GUID>“. Der DN des gelöschten Benutzerobjekts „Yusuf Dikmenoglu“ sieht z.B. so aus: CN=Yusuf Dikmenoglu\0ADEL:4b506a93-d721-4cbf-87dc-565939cf07af,CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de
Das gelöschte Objekt wandert deshalb zuerst in den Container Deleted Objects, damit jeder Domänencontroller (DC) z.B. in einer weltweit verteilten Umgebung von der Löschung des Objekts in Kenntnis gesetzt wird, ehe das Objekt endgültig aus dem AD gelöscht wird. Gerade in größeren AD-Umgebungen mit einem komplexen Replikationszeitplan, ist diese Vorgehensweise für das Löschen von Objekten zwingend. Denn würde das Objekt nach dem löschen direkt aus der AD-Datenbank entfernt werden, würden die anderen DCs von dieser Löschung nichts mitbekommen und es entständen Lingering Objects (zu Deutsch: herumlungernde Objekte).
Lingering Objects (veraltete Objekte)
Das gelöschte Objekt verbleibt im Container Deleted Objects 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 ab Windows Server 2003 SP1 oder ab Windows Server 2003 R2 SP2 beträgt die TSL 180 Tage. Erst nach Ablauf der TSL Zeit, wird das Objekt nun endgültig vom Garbage Collection Prozess der standardmäßig alle 12 Stunden auf jedem DC läuft, aus dem AD entfernt.
Die Tombstone Lifetime
Dabei können Objekte aus der Konfigurations-, Domänen- und Anwendungsverzeichnispartition (wie z.B. ForestDNSZones und DomainDNSZones) gelöscht werden, aber nicht aus der Schemapartition! Schemaobjekte (Attribute und Klassen) können nicht entfernt werden, höchstens deaktiviert.
Ab Windows Server 2003 kann ein gelöschtes Objekt, sprich das Tombstone mit wenigen Attributen reanimiert werden. Wurde ein Objekt gelöscht, wird der DN vom Ursprungsort des Objekts im Attribut lastKnownParent eingetragen. Ein Objekt das autoritativ wiederhergestellt wurde, enthält ebenfalls im Attribut lastKnownParent den Ursprungsort. Oder wenn ein Objekt in den Container LostAndFound verschoben wird (bei einem Konflikt), der in den Verzeichnispartitionen Konfigurationspartition, Domänenpartition und Anwendungsverzeichnispartitionen wie die beiden DNS-Partitionen ForestDNSZones und DomainDNSZones existiert, wird im Attribut lastKnownParent ebenso der Ursprungsort des Konfliktobjekts eingetragen. Beim verschieben oder kopieren eines Objekts wird kein Wert im Attribut lastKnownParent eingetragen.
Wenn nun in der Domäne blog.dikmenoglu.de der Benutzer „Yusuf“ der sich in der OU „IT“ befindet gelöscht wird, enthält das Attribut lastKnownParent des gelöschten Benutzerobjekts im Container Deleted Objects der Domänenpartition den folgenden Wert:
OU=IT,DC=blog,DC=dikmenoglu,DC=de
Dadurch lassen sich wiederhergestellte Tombstones, autoritativ wiederhergestellte Objekte oder Konfliktobjekte die sich im Container LostAndFound befinden ausfindig machen, in dem man eine Abfrage nach dem Attribut lastKnownParent durchführt und dabei diesen LDAP-Filter verwendet:
(&(objectclass=*)(lastKnownParent=*))
Möchte man sich lediglich Benutzerkonten anzeigen lassen, so kann man z.B. bei einer benutzerdefinierten gespeicherten Abfrage diesen Filter verwenden:
(objectcategory=person)(lastKnownParent=*)
Den Container Deleted Object mit LDP anzeigen
Der versteckte Container Deleted Objects wird weder in der MMC Active Directory-Benutzer und -Computer, noch in ADSIEdit.msc angezeigt. Stattdessen kann man sich mit LDP.exe oder z.B. dem AD Explorer den Container Deleted Objects anzeigen lassen. Wobei der Container in den Anwendungsverzeichnispartitionen lediglich mit LDP angezeigt werden kann und nicht mit dem AD Explorer. Natürlich können aber auch andere LDAP-Browser verwendet werden.
- Das LDP.exe befindet sich unter Windows 2000 und Windows Server 2003 in den Windows Support Tools und ist bereits ab Windows Server 2008 on Bord.
- Unter Start - Ausführen startet man als Erstes das LDP
- Danach muss man sich mit einem DC verbinden. Dazu gilt es unter Windows Server 2003 im Menüpunkt Connection die Option Connect… aufzurufen und im darauffolgenden Fenster einen DC einzutragen. Unter Windows Server 2008 heißt der Menüpunkt Remotedesktopverbindung und die Option Verbinden…
- Nun gilt es unter Connection/Remotedesktopverbindung - Bind…/Gebunden… ein entsprechendes Benutzerkonto (z.B. den Domänen-Admin) anzugeben, um sich mit diesem Benutzer an das AD zu „binden“.
- Anschließend muss der Distinguished Name (DN) des entsprechenden Deleted Objects Container unter View/Ansicht - Tree/Struktur angegeben werden.
Der DN des Container Deleted Objects in der Konfigurationspartition lautet:
CN=Deleted Objects,CN=Configuration,DC=Root-Domäne
In der Domänenpartition lautet der DN von Deleted Objects wie folgt:
CN=Deleted Objects,DC=blog,DC=dikmenoglu,DC=de
Der DN von Deleted Objects in den beiden DNS-Anwendungsverzeichnispartitionen lautet folgendermaßen:
CN=Deleted Objects,DC=ForestDNSZones,DC=Root-Domäne
CN=Deleted Objects,DC=DomainDNSZones,DC=Domäne,DC=de
- Nach dem man sich mit dem Container Deleted Objects verbunden hat, sieht man den Eintrag zwar auf der linken Seite im LDP-Fenster, jedoch erscheinen unter dem Eintrag keine weiteren Einträge, sprich die gelöschten Objekte bzw. Tombstones kommen nicht zum Vorschein. Diese erscheinen erst, wenn unter dem Menüpunkt Options/Optionen der Menüeintrag Controls/Steuerelemente ausgewählt und das LDAP-Control Return deleted objects (1.2.840.113556.1.4.417) als aktives Steuerelement eingecheckt wurde.
- Um nun ein Tombstone mit LDP zu reanimieren, müssen zwei Attribute im Tombstone verändert werden. Dazu klickt man mit rechts auf das zu wiederherstellende Objekt und wählt die Option Modify/Ändern. Danach muss zum einen der Wert im Attribut isDeleted gelöscht werden (den Wert aus FALSE zu setzen reicht nicht aus) und zum anderen, muss der DN des Objekts geändert werden. Dabei muss das Tombstone auch nicht zwingend an seinem Ursprungsort, der im Attribut lastKnownParent eingetragen ist, wiederhergestellt werden. Mit einem Klick auf Run/Ausführen wird das Tombstone dann wiederhergestellt.
-
In größeren AD-Umgebungen kann es im Container Deleted Objects das sich in der Domänenpartition befindet, durch die vielen gelöschten Objekte sehr unübersichtlich werden. Um sich lediglich die gelöschten Objekte eines bestimmten Zeitraums auf der rechten Seite im LDP anzeigen zu lassen, muss nach einem bestimmten Attribut in den gelöschten Objekten (den Tombstones) gesucht werden. Das Attribut in dem das Löschdatum enthalten ist lautet whenChanged.
Möchte man sich z.B. die Objekte die in den letzten 10 Tagen gelöscht wurden anzeigen, so klickt man auf der linken Seite im LDP mit rechts auf den Eintrag CN=Deleted Objects,DC=Domäne,DC=de und wählt die Option Search/Suchen. Als Filter könnte dieser eingesetzt werden: (&(objectclass=user)(whenchanged>=20090724023000.0Z)). Im Feld Attribute können die gewünschten Attribute des Tombstones angegeben werden, die ebenfalls angezeigt werden sollen. Oder es wird ein Wildcard (das Sternchen *) angegeben, um alle Attribute die im Tombstone enthalten sind anzuzeigen. Dabei muss der Wert, sprich das Datum und die Uhrzeit im Attribut whenChanged in folgender Notation angegeben werden:
2009(Jahr) 07(Monat) 24(Tag) 02(Stunden) 30(Minuten) 00(Sekunden).0Z
Man beachte bei der Zeitangabe, dass das Attribut whenChanged nicht zwischen den DCs repliziert wird.
Das bedeutet, dass der Wert im Attribut whenChanged sich von DC zu DC unterscheidet.
- Schaut man sich die LDAP-Controls im LDP unter Windows Server 2008 R2 genauer an, entdeckt man zwei neue Einträge. Die beiden neuen Einträge sind:
Mit dem LDAP-Control Return deactivated links (1.2.840.113556.1.4.2065) werden die verknüpften Attribute bei aktiviertem AD-Papierkorb eines Objekts angezeigt (z.B. das memberOf Attribut eines Benutzerobjekts). Denn wenn der AD-Papierkorb im Windows Server 2008 R2 aktiviert wurde, werden die verknüpften Attribute (Forward- und Backlink) beim Löschen eines Objekts nicht entfernt. Somit ist auch das Geheimnis des AD-Papierkorbs entlüftet, wie es mit den verknüpften Attributen umgeht.
Weitere Informationen:
Last-Known-Parent Attribute (Windows)
When-Changed Attribute (Windows)
Der Active Directory-Papierkorb im Windows Server 2008 R2
Verknüpfte Attribute
Viewing deleted objects in Active Directory
How to let non-administrators view the Active Directory deleted objects container in Windows Server 2003 and in Windows 2000 Server
Searching for Deleted Objects
Das versehentliche Löschen von Active Directory-Objekten ist in Active Directory (AD) bzw. Active Directory Domain Services (AD DS), als auch in Active Directory Lightweight Directory Services (AD LDS, ehemals Active Directory Application Mode, kurz ADAM) Umgebungen mehr als ärgerlich. Denn schnell sind mit zwei Mausklicks ein oder mehrere Objekte gelöscht. Hoffentlich existiert in so einem Fall eine aktuelle und vor allem funktionierende Sicherung, mit dem das verlorene Objekt wiederhergestellt werden kann. Bis jedoch das passende Sicherungsband gefunden, eingelegt und das Objekt letztenendes wiederhergestellt ist, können diese Arbeiten sehr zeitintensiv und aufwändig sein.
Die Möglichkeiten die einem bei der Wiederherstellung zur Verfügung stehen, sind unter:
-
Windows 2000 = Autoritative Wiederherstellung
-
Windows Server 2003 = Autoritative Wiederherstellung, Tombstone reanimieren
-
Windows Server 2003 R2 = Autoritative Wiederherstellung, Tombstone reanimieren
-
Windows Server 2008 = Autoritative Wiederherstellung, Tombstone reanimieren
-
Windows Server 2008 R2 = AD-Papierkorb, Autoritative Wiederherstellung, Tombstone reanimieren (bei deaktiviertem und aktiviertem AD-Papierkorb)
Die autoritative Wiederherstellung
Existiert eine aktuelle und funktionierende System State-Sicherung, kann mit einer autoritativen Wiederherstellung das Objekt mit all seinen Informationen die es zum Zeitpunkt der Sicherung hatte, wiederhergestellt werden. Dabei darf die Systemstatus-Sicherung (auf englisch: System State) nicht älter als die Tombstone-Lifetime (TSL) sein, denn ansonsten entstehen Lingering Objects. Die TSL einer Gesamtstruktur gibt das maximale Alter einer Systemstatus-Sicherung an, die für eine Rücksicherung verwendet werden darf.
Ein AD-Objekt wird in der Kommandozeile mit dem Befehl Ntdsutil-authoritative restore hergestellt. Dabei wird die Versionsnummer um 100.000 erhöht, damit das rückgesicherte Objekt nach der AD-Replikation auf die Replikationspartner erhalten bleibt und nicht von einem anderen DC direkt wieder gelöscht wird.
Problematisch ist allerdings die Wiederherstellung der Gruppenmitgliedschaften eines gelöschten Benutzers, die sogenannten Backlinks. Zur Wiederherstellung von Gruppenmitgliedschaften sind weitere aufwändige Schritte notwendig. Das hat sich zwar mit Windows Server 2003 SP1 etwas entschärft, jedoch ist weiterhin der Aufwand zum Rücksichern dieser Backlinks recht hoch.
Der Nachteil einer autoritativen Wiederherstellung wäre, dass der Domänencontroller (DC) im Modus Verzeichnisdienste wiederherstellen gestartet werden muss und dadurch zwei Neustarts notwendig sind. Somit würde der DC während der ganzen Zeit der Wiederherstellung nicht zur Verfügung stehen.
Diese Vorgehensweise ist seit der Einführung des Active Directory mit Windows 2000 gleich geblieben.
Weitere Details stehen in dem Artikel:
Active Directory Wiederherstellung
Ist eine Wiederherstellung in einer AD LDS-Umgebung notwendig, so ist es erforderlich die AD LDS-Instanz vorher zu stoppen. Allerdings muss für die Wiederherstellung der Server nicht im Modus Verzeichnisdienste wiederherstellen gestartet werden.
Wiederherstellen von AD LDS-Instanzdaten
Die Tombstone-Reanimierung
Eine andere Variante die seit Windows Server 2003 zur Verfügung steht, ist das reanimieren des Tombstones (zu Deutsch: Grabstein). Diese Art der Wiederherstellung hat den Vorteil, dass das Tombstone online ohne, dass der DC neu gestartet werden muss, jederzeit wiederhergestellt werden kann. Auch in einer AD LDS-Umgebung muss dazu die AD LDS-Instanz nicht offline genommen werden. Das gelöschte Objekt (das Tombstone) kann natürlich nur reanimiert werden, solange die Tombstone Lifetime nicht abgelaufen ist. Der Nachteil dieser Variante wiederum wäre, dass beim Wiederbeleben des Tombstones nicht alle Informationen eines Objekts automatisch wiederhergestellt werden.
Denn wenn ein Objekt gelöscht wird, verschwindet es nicht sofort aus der Active Directory-Datenbank (NTDS.dit). Das Objekt wird stattdessen vom Active Directory als gelöscht markiert, indem das Attribut Is-Deleted des Objekts auf den Wert True gesetzt wird. Aber es werden die meisten Attribute von dem Objekt für immer entfernt. Danach wird das Objekt in den versteckten Container Deleted Objects (der in jeder Verzeichnispartitionen existiert) verschoben und wird ab diesem Zeitpunkt als Tombstone bezeichnet. Wird also ein Benutzer gelöscht, so landet das Benutzerkonto mit wenigen Werten im Container „Deleted Objects“ der Domänenpartition und wird erst nach Ablauf der TSL vom Garbage Collection Prozess ein für allemal aus dem AD entfernt.
Landet das Tombstone im Container „Deleted Objects“, erhält es einen speziellen Relative Distinguished Name (RDN) der so aussieht: „CN=<Alter RDN>\0ADEL:<Object-GUID>“. Beim Wiederbeleben des Tombstone wird das Objekt dann nur noch mit einigen wenigen Werten (z.B. ObjectGUID oder ObjectSID) wiederhergestellt.
Der Container „Deleted Objects“ wird aber nicht in den AD Snap-Ins oder im ADSIEdit angezeigt. Stattdessen können die Tombstones mit ADRestore.Net, ADRestore oder LDP.exe angezeigt sowie wiederhergestellt werden.
ADRestore.NET
ADRestore
Die restlichen Werte die in einem wiederhergestellten Tombstone fehlen, könnten mit einem der folgenden Tools, von einem zuvor erstellten AD-Snapshot unter Windows Server 2008 bzw. Windows Server 2008 R2 wiederhergestellt werden.
Directory Service Comparison Tool 1.3.2.X
AD Explorer
1Identity
Die Grabstein-Lebenszeit (Tombstone Lifetime)
Die Tombstone Lifetime wird mit dem Installieren des allerersten DCs für die komplette Gesamtstruktur festgelegt. Dabei ist es entscheidend welches Server-Betriebssystem mit welchem Service-Pack auf dem Server installiert ist, mit dem die Gesamtstruktur erstellt wird. Das Installieren eines Service-Packs auf bestehenden DCs, verändert niemals die Tombstone Lifetime. Es müsste schon die Gesamtstruktur neu installiert werden.
Wie und wo man die TSL überprüfen kann, steht neben weiteren Details in dem folgenden Artikel.
Die Tombstone Lifetime
Die Tombstone-Lifetime beträgt unter den Betriebssystemen:
-
Windows 2000 (mit allen SPs) = 60 Tage
-
Windows Server 2003 ohne SP = 60 Tage
-
Windows Server 2003 ab Service Pack 1 = 180 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert mit beiden R2-CDs = 60 Tage
-
Windows Server 2003 R2 mit Service Pack 1, installiert nur mit der ersten R2-CD = 180 Tage
-
Windows Server 2003 R2 ab Service Pack 2 (installiert mit der ersten oder beiden R2-CDs) = 180 Tage
-
Windows Server 2008 (mit allen SPs) = 180 Tage
-
Windows Server 2008 R2 (mit allen SPs) = 180 Tage
Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung unter Windows Server 2003/2003 R2, Windows Server 2008 und Windows Server 2008 R2, bei deaktiviertem AD-Papierkorb
Der Active Directory-Papierkorb unter Windows Server 2008 R2
Ein absolutes Highlight im Windows Server 2008 R2 ist der Papierkorb für gelöschte Active Directory-Objekte. Wird ein Active Directory-Objekt in den Active Directory Domain Services (AD DS) oder Active Directory Lightweight Directory Services (AD LDS) gelöscht, kann es Dank des AD-Papierkorbs schnell wiederhergestellt werden. Der AD-Papierkorb steht in AD DS und AD LDS-Umgebungen zur Verfügung. Der große Vorteil des AD-Papierkorbs ist, dass das Objekt mit all seinen Informationen die es zum Zeitpunkt der Löschung hatte wiederhergestellt wird. Das bedeutet, alle Attribute samt allen Backlinks und somit z.B. den Gruppenmitgliedschaften eines Benutzers, werden hergestellt. Nach der Wiederherstellung ist auch der Zugriff auf die bestehenden Objekte und Ressourcen wieder gegeben.
Dafür wird weder eine System-State Sicherung benötigt, noch muss der DC im Verzeichnisdienste wiederherstellen Modus gestartet werden. Die Wiederherstellung findet im laufenden Betrieb statt.
Diese neue Technik steht ausschließlich in den folgenden Server-Versionen zur Verfügung:
-
Windows Server 2008 R2 Standard
-
Windows Server 2008 R2 Enterprise
-
Windows Server 2008 R2 Datacenter
Der AD-Papierkorb steht in den folgenden Versionen nicht zur Verfügung:
- Windows Server 2008 R2 für Itanium basierte Systeme
- Windows Web Server 2008 R2
Jedoch ersetzt diese Funktion niemals eine regelmäßige System State-Sicherung!
Die Voraussetzungen um den Active Directory-Papierkorb unter Windows Server 2008 R2 zu nutzen
Die Voraussetzungen um den AD-Papierkorb zu nutzen sind:
-
Der AD-Papierkorb steht in den AD DS und AD LDS-Umgebungen erst im Gesamtstrukturfunktionsmodus Windows Server 2008 R2 zur Verfügung. Es müssen also alle Domänencontroller aus allen Domänen der Gesamtstruktur oder alle Server auf denen eine AD LDS-Instanz konfiguriert ist, unter Windows Server 2008 R2 laufen!
Den ersten Windows Server 2008 R2 DC zur Gesamtstruktur hinzufügen
-
Der AD-Papierkorb ist standardmäßig deaktiviert, sowohl bei einer Domänenaktualisierung oder dem neu Aufsetzen einer Windows Server 2008 R2 Gesamtstruktur im Gesamtstrukturfunktionsmodus „Windows Server 2008 R2“. Der AD-Papierkorb muss explizit in der AD-Powershell aktiviert werden. Dieser Schritt ist ein irreversibler Vorgang und kann danach nicht mehr rückgängig gemacht werden!
Nach dem Aktivieren des AD-Papierkorbs lässt sich dieses Feature mit Bordmitteln über die AD-Powershell und LDP.exe nutzen. Es existiert keine grafische Oberfläche in der man mit der Maus die Funktion aktivieren kann. Jedoch lassen sich mit dem Tool LDP oder den beiden Tools ADRestore.Net und ADRestore, ebenfalls die gelöschten Objekte im AD-Papierkorb anzeigen sowie wiederherstellen.
Kann der AD-Papierkorb für eine einzige Domäne in der Gesamtstruktur aktiviert werden?
So wie bei der Tombstone Lifetime ist es nicht möglich, den AD-Papierkorb „pro Domäne“ zu aktivieren. Wenn die Voraussetzungen erfüllt sind, kann diese Funktion nur auf der Gesamtstrukturebene mit „Organisations-Admin“ Rechten für alle Domänen aktiviert werden. Anschließend steht jeder Domäne sein eigener AD-Papierkorb zur Verfügung. Der AD-Papierkorb existiert also "pro Domäne" und nicht "pro Gesamtstruktur"!
Die Funktionsweise des Active Directory-Papierkorbs unter Windows Server 2008 R2
Der AD-Papierkorb baut auf der Technik der Tombstone-Reanimierung auf. Jedoch werden vom gelöschten Objekt dafür keine Attribute vom System entfernt und es bleiben alle Attribute erhalten. Das Objekt wird logisch gelöscht bzw. inaktiv gesetzt, was ein neues Stadium eines gelöschten Objekts ist, das mit Windows Server 2008 R2 eingeführt wurde. In der AD-Datenbank wurde dazu das Speicherformat der Objektlinks geändert. Wird ein Objekt gelöscht, so erhält das Attribut isDeleted im Objekt den Wert TRUE. Das gelöschte Objekt wird nach wie vor in den versteckten Container Deleted Objects verschoben und sein Distinguished Name (DN) erhält dadurch einen neuen Wert. Das Objekt in „Deleted Objects“ behält seinen logischen Löschzustand solange bei, bis die Deleted Object Lifetime (DOL) abgelaufen ist. Nach Ablauf der DOL wandelt sich das gelöschte Objekt zu einem "recycled Objekt". Das recycled Objekt wird dann endgültig vom Garbage Collection Prozess nach Ablauf der Recycled Object Lifetime (ROL) aus der AD-Datenbank entfernt. Unter Windows Server 2008 R2 gibt es nun neben der Tombstone Lifetime zusätzlich die Deleted Object Lifetime (kurz DOL) und Recycled Object Lifetime (kurz ROL).
Die Deleted Object Lifetime wird durch den Wert im neuen Attribut msDS-DeletedObjectLifetime bestimmt. Denn bei einer Domänenaktualisierung auf Windows Server 2008 R2 ist eines der Schema-Aktualisierungen mit Adprep /Forestprep (von der Windows Server 2008 R2 DVD) das Hinzufügen des neuen Attributs msDS-DeletedObjectLifetime. Wenn jedoch eine Gesamtstruktur auf Basis von Windows Server 2008 R2 erstellt wird, befinden sich bereits alle benötigten Attribute im Schema und das Adprep muss in keinster Weise ausgeführt werden. Die Recycled Object Lifetime hingegen, erhält seinen Wert aus dem Attribut tombstoneLifetime.
Ist die Zeit des im Attribut msDS-DeletedObjectLifetime definierten Werts abgelaufen, wandelt sich das logisch gelöschte Objekt zum „recycled Objekt“. Zusätzlich erhält das Attribut isRecycled im Objekt den Wert TRUE. Dabei werden die gleichen Attribute vom Objekt entfernt, wie es seit Windows Server 2003 bei einem Tombstone der Fall ist. Oder anders ausgedrückt, im recycled Objekt bleiben standardmäßig die gleichen Attribute erhalten wie bei einem Tombstone unter Windows Server 2003, Windows Server 2008 oder Windows Server 2008 R2 bei deaktiviertem AD-Papierkorb. Von der Begrifflichkeit her entspricht ein „recycled Objekt“ einem klassischen Tombstone.
Auch können in einem recycled Objekt durch das vierte Bit im searchFlags (in Dezimal 8) des gewünschten Attributs, weitere Attribute gespeichert werden. Daher das ein "recycled Object" nichts anderes als ein Tombstone ist, lässt es sich natürlich auch mit wenigen Attributen mit z.B. LDP, ADRestore oder ADRestore.NET reanimieren. Des Weiteren kann ein gelöschtes Objekt das sich nach Ablauf der DOL zu einem recycled Objekt gewandelt hat, auch nicht mehr aus dem AD-Papierkorb mit allen Werten wiederhergestellt sondern lediglich als Tombstone reanimiert werden.
Das recycled Objekt bleibt weiterhin in dem Container Deleted Objects, bis die im Attribut tombstoneLifetime definierte Zeit abläuft. Anschließend wird das Objekt vom Garbage Collection Prozess unwiderruflich aus dem AD entfernt.
Das bedeutet im Klartext, bei aktiviertem AD-Papierkorb lässt sich ein gelöschtes Objekt nur während der DOL mit allen Werten wiederherstellen. Die Möglichkeiten zum Wiederherstellen sind dabei:
-
Das Wiederherstellen aus dem AD-Papierkorb mit der AD-Powershell, LDP, ADRestore.NET oder ADRestore.
-
Eine autoritative Wiederherstellung.
Achtung: Wird der AD-Papierkorb aktiviert, wandeln sich alle AD-Objekte die bis zum Aktivieren des AD-Papierkorbs gelöscht wurden (also alle Tombstones), zu recycled Objekten. Diese Objekte können in der AD-Powershell mit einem bestimmten Befehl angezeigt werden (siehe unten). Jedoch können diese Objekte nicht mit Hilfe des AD-Papierkorbs bzw. der Tombstone-Reanimierung wiederhergestellt werden. Die beiden Tools ADRestore.NET und ADRestore zeigen ebenfalls diese Tombstones nicht an. Das Tool LDP zeigt zwar ebenfalls die Objekte an, ist aber auch nicht in der Lage die Objekte wiederherzustellen. Der einzige Weg diese Objekte herzustellen, ist eine autoritative Wiederherstellung von einer Systemstatus-Sicherung, die vor dem aktivieren des AD-Papierkorbs durchgeführt wurde.
Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL)
Standardmäßig enthält das Attribut msDS-DeletedObjectLifetime keinen Wert. Es ist <Nicht festgelegt>. In diesem Fall wird der Wert aus der Recycled Object Lifetime festgelegt. Man kann aber natürlich auch jederzeit manuell einen Wert im Attribut msDS-DeletedObjectLifetime definieren.
Die ROL wiederum erhält seinen Wert aus dem Attribut tombstoneLifetime, denn die ROL hat kein eigenes Attribut wie die DOL. Das bedeutet, wenn ein Objekt gelöscht wird und im Attribut msDS-DeletedObjectLifetime ist kein Wert definiert, behält das Objekt für 60/180 Tage seinen logischen Löschzustand bei und wird anschließend zum recycled Objekt umgewandelt. Nach weiteren 60/180 Tagen (nach Ablauf der Tombstone Lifetime) wird es dann endgültig vom Garbage Collection Prozess aus der AD-Datenbank entfernt. Das Objekt bleibt somit über den gesamten Zeitraum der DOL und ROL im AD erhalten, ehe es definitiv aus dem AD gelöscht wird.
Ist hingegen im Attribut msDS-DeletedObjectLifetime ein Wert definiert, so beträgt die DOL den eingetragenen Wert in Tagen und es wird nicht der Wert aus dem Attribut tombstoneLifetime angenommen. Wenn daher der Bedarf besteht, ein gelöschtes Objekt länger als die Zeit das im Attribut tombstoneLifetime eingetragen ist aus dem AD-Papierkorb wiederherzustellen, so gilt es einen eigenen Wert im Attribut msDS-DeletedObjectLifetime zu definieren.
Enthält z.B. das Attribut tombstoneLifetime als Wert 180 und ist im Attribut msDS-DeletedObjectLifetime kein Wert eingetragen, so wird ein gelöschtes Objekt erst nach 360 Tagen vom Garbage Collection Prozess für immer aus dem AD entfernt.
Der Vorgang eines gelöschten AD-Objekts sowie seine Wiederherstellung, bei aktiviertem AD-Papierkorb unter Windows Server 2008 R2
Die Deleted Object Lifetime (DOL) und Recycled Object Lifetime (ROL) überprüfen und bearbeiten
-
Das Attribut msDS-DeletedObjectLifetime befindet sich im gleichen Container wie das Attribut tombstoneLifetime, nämlich in den Eigenschaften des Containers:
CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
-
Kontrollieren kann man das Attribut msDS-DeletedObjectLifetime z.B. mit Dsquery.
Der Befehl lautet:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne" -attr msDS-DeletedObjectLifetime
Falls kein Wert angezeigt wird, gilt der Standardwert aus dem Attribut tombstoneLifetime von 60/180 Tagen (sofern nicht manuell geändert). Ansonsten gilt der angezeigte Wert in Tagen.
-
Das Attribut tombstoneLifetime lässt sich mit Dsquery folgendermaßen abfragen:
Dsquery * "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" -attr tombstoneLifetime
Falls kein Wert angezeigt wird, gilt als Wert 60 Tage. Ansonsten gilt auch hier der angezeigte Wert in Tagen.
-
Die DOL und das Attribut tombstoneLifetime lassen sich auch mit ADSIEdit überprüfen und bearbeiten. Dazu gilt es zuerst zum folgenden Container zu navigieren:
CN=Directory Services,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne
Dort befindet sich in den Eigenschaften des Containers zum einen das Attribut msDS-DeletedObjectLifetime und zum anderen das Attribut tombstoneLifetime. Ist im Attribut msDS-DeletedObjectLifetime ein Wert gesetzt, beträgt die DOL den eingetragenen Wert in Tagen. Steht im Attribut als Wert hingegen <Nicht festgelegt>, so beträgt die DOL den Wert aus dem Attribut tombstoneLifetime. Wenn im Attribut tombstoneLifetime als Wert <Nicht festgelegt> ist, so gilt als Wert 60 Tage. Ansonsten beträgt die Zeit den eingetragenen Wert in Tagen.
-
Die DOL lässt sich auch über die AD-Powershell bearbeiten. Dazu ist die AD-Powershell explizit als Administrator aufzurufen und der folgende Befehl einzugeben:
Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“msDS-DeletedObjectLifetime” = Wert}
Das Attribut tombstoneLifetime lässt sich im Übrigen auch auf die gleiche Weise verändern: Set-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Domäne,DC=de” –Partition “CN=Configuration,DC=Domäne,DC=de” –Replace:@{“tombstoneLifetime” = Wert}
Aktivieren und nutzen des AD-Papierkorbs in der Active Directory-Powershell
Nach Ausführen von Dcpromo steht die Active Directore-Powershell mit 76 AD-Cmdlets auf dem DC zur Verfügung. Mit den beiden AD-Powershell Cmdlets Get-ADObject und Restore-ADObject ist es möglich, gelöschte AD-Objekte anzuzeigen sowie wiederherzustellen. Dabei ruft man mit Get-ADObject das gelöschte Objekt auf und übergibt es durch die Pipeline dem Restore-ADObject Cmdlet.
Zum Aktivieren des AD-Papierkorbs ist die folgende Vorgehensweise notwendig:
-
Im ersten Schritt muss mit „Organisations-Admin“ Rechten der AD-Papierkorb in der Root-Domäne und zwar für alle Domänen in der Gesamtstruktur aktiviert werden. Der Befehl dazu lautet:
Enable-ADOptionalFeature „Recycle Bin Feature“ -Scope ForestorConfigurationset -Target “Root-Domäne*” (*DNS- oder NetBIOS-Name der Root-Domäne)
Es folgt eine Warnung die besagt, dass bei Bestätigen der Meldung dieser Vorgang irreversibel ist. Nach dem Aktivieren des AD-Papierkorbs, lässt es sich nicht mehr deaktivieren!
-
Wenn der AD-Papierkorb aktiviert wurde, wird im Attribut msDS-EnabledFeature das sich in den Eigenschaften des Containers "CN=Partitions,CN=Configuration,DC=Root-Domäne" befindet, als Wert "CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne" eingetragen.
-
Der folgende Befehl zeigt detaillierte Informationen über die zur Verfügung stehenden Optional Feature im Active Directory an:
Get-ADOptionalFeature -Filter * oder Get-ADOptionalFeature -Filter {Name -Like "*"}
-
Wurde ein Benutzerkonto aus Versehen gelöscht, so kann man sich das Konto wenn der sAMAccountName bekannt ist, auf diese Art anzeigen lassen:
Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} -Includedeletedobjects
Wiederherstellen lässt sich das Benutzerkonto dann mit diesem Befehl:
Get-ADObject -Filter {sAMAccountname –eq „Yusuf“} –Includedeletedobjects | Restore-ADObject
-
Ist der „Anzeigename“ eines Benutzerkontos bekannt, so lautet die Abfrage wie folgt. Aber Vorsicht, der „Anzeigename“ ist nicht der Name, der in der MMC Active Directory-Benutzer und -Computer in der Spalte „Name“ angezeigt wird. Denn dieser Wert wiederum, wird im Attribut name gespeichert.
Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects
Wiederherstellen lässt sich das Benutzerkonto dann so:
Get-AdObject –Filter {displayname –eq “Yusuf Dikmenoglu”} –Includedeletedobjects | Restore-ADObject
-
Ein bestimmtes Benutzerkonto wird auf diese Weise angezeigt:
Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects
Oder so:
Get-ADOject -Filter 'Name -Like "Yusuf*"' -Searchscope Subtree -Includedeletedobjects | ft -a
Wiederherstellen kann man dann das Benutzerkonto so:
Get-ADObject -Filter {Name -Like “*Name*”} –Includedeletedobjects | Restore-ADObject
-
Dieser Befehl zeigt die gelöschten Objekte im Container "Deleted Objects" an:
Get-ADObject -ldapFilter:”(msDS-LastKnownRDN=*)" -Includedeletedobjects
Wiederherstellen kann man ein Benutzerkonto auch wie folgt:
Get-ADObject -ldapFilter:"(msDS-LastKnownRDN=<Benutzer>)" -Includedeletedobjects | Restore-ADObject
-
Der nachfolgende Befehl zeigt die gelöschten sowie recycelten Objekte mit detailierten Informationen an, die in einer bestimmten OU waren. Mit diesem Befehl können auch die recycelten Objekte angezeigt werden, die vor dem aktivieren des AD-Papierkorbs gelöscht wurden:
Get-ADObject -Filter {Lastknownparent -eq "OU=<OU>,DC=Domäne,DC=de"} -Searchbase "CN=Deleted Objects,DC=Domäne,DC=de" -includedeletedobjects -properties *
-
Mit dem folgenden Befehl kann man sich alle gelöschten Objekte, egal welcher Klasse, aus dem versteckten Container „Deleted Objects“ der Domänenpartition anzeigen lassen:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects | Format-List
-
Oder wer die Objekte jeglicher Klassen im schnellen Überblick haben möchte, verwendet diesen Befehl:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=*)“ –Includedeletedobjects
-
Die gelöschten AD-Objekte der Klasse „User“ (z.B. Benutzerkonten) lassen sich wie folgt anzeigen:
Get-ADObject –Searchbase „CN=Deleted Objects,DC=Domäne,DC=de“ –LdapFilter „(objectclass=User)“ –IncludedeletedObjects
-
Wurde ausversehen eine OU mit etlichen Benutzern gelöscht, so muss zuerst die OU wiederhergestellt werden, ehe dann die Benutzer wiederhergestellt werden können. Doch bevor die OU wiederhergestellt werden kann, wird die GUID der gelöschten OU benötigt. Diese erfährt man durch das Attribut lastknownparent eines Benutzers, das sich in der OU befand. Der Befehl würde so aussehen:
Get-ADOject -filter 'name -like "Yusuf*"' -searchscope subtree -Includedeletedobjects -properties lastknownparent
Dann kann mit diesem Befehl zuerst die OU wiederhergestellt werden:
Restore-ADObject -identity <GUID der OU>
Alle Objekte die sich in der OU befanden, können mit diesem Befehl wiederhergestellt werden:
Get-ADObject -ldapfilter "(lastknownparent=OU=<OU>,DC=Domäne,DC=TLD)" -Includedeletedobjects | Restore-ADObject
Die AD-Powershell im Windows Server 2008 R2
Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit ADRestore.NET und ADRestore
-
Das Tool ADRestore.NET muss zuerst installiert werden, lässt sich dann aber sehr simpel mit der Maus bedienen und ist vor allem selbsterklärend. Die gelöschten Objekte lassen sich mit einem Mausklick anzeigen und mit einem weiteren wiederherstellen.
ADRestore.NET
-
Das Kommandozeilentool ADRestore lässt sich nach dem Download ohne eine Installation in einer Kommandozeile ausführen. Auch dieses Tool ist selbsterklärend.
ADRestore
-
Ein weiteres kostenloses Tool ist das ADRecycleBin. Es zeigt die gelöschten Objekte an und stellt diese wieder her.
ADRecycleBin
Anzeigen und Wiederherstellen der gelöschten Objekte aus dem AD-Papierkorb mit LDP
Die gelöschten Objekte im Container Deleted Objects lassen sich ebenfalls mit dem im Betriebssystem integrierten LDAP-Tool LDP anzeigen sowie wiederherstellen lassen.
Die Vorgehensweise wäre wie folgt:
-
Zuerst gilt es auf dem DC unter Start-Ausführen-LDP.exe das Tool aufzurufen.
-
Unter Optionen ist dann in den Steuerelementen im Feld Vordefiniert laden die Option Return deleted objects auszuwählen. Wählt man an dieser Stelle stattdessen die Option Return recycled objects aus, kann man sich bei gleicher Vorgehensweise die „recycelten Objekte“ anzeigen lassen.
-
Danach wählt man unter Remotedesktopverbindung den Punkt Gebunden... aus. Grandiose Bezeichnungen.
-
Anschließend gibt man unter Ansicht-Struktur den Distinguished Name (DN) der entsprechenden (meistens) Domänenpartition an, z.B. DC=blog,DC=dikmenoglu,DC=de
-
Nun erweitert man zuerst auf der linken Seite die entsprechende Verzeichnispartition und erweitert auch den Eintrag Deleted Objects mit einem Doppelklick. Jetzt erscheinen die gelöschten Objekte.
-
Mit einem Rechtsklick auf das wiederzuherstellende Objekt, wählt man den Punkt Ändern aus.
-
Unter Eingabe bearbeiten gibt man im Feld Attribut isDeleted ein.
-
Das Feld Werte bleibt leer.
-
Unter Vorgang wählt man Löschen und klickt auf Eingabe.
-
Jetzt müssen die gleichen Schritte mit dem Attribut distinguishedName durchgeführt werden.
-
Im Feld Werte ist nun der original DN des Objekts einzugeben. Daher ist es stets sinnvoll, eine Liste mit allen Objekten und deren DN zu besitzen.
-
Unter Vorgang wählt man Ersetzen und klickt auf Eingabe.
-
Nach dem aktivieren von Erweitert führt man die Wiederherstellung mit einem Klick auf Ausführen durch.
Fallbeispiele
-
Wenn z.B. ein Benutzer Mitglied der Gruppe1 ist, beide Objekte nacheinander gelöscht werden, aber nur das Benutzerkonto aus dem AD-Papierkorb wiederhergestellt wird, befindet sich anschließend das Benutzerkonto logischerweise nicht mehr in der Gruppe1. Wird jedoch die Gruppe1 ebenfalls aus dem AD-Papierkorb wiederhergestellt, werden automatisch Forward- und Back-Link wiederhergestellt. Das Benutzerkonto ist wieder Mitglied der Gruppe1.
-
Existiert eine Gruppenverschachtelung, so das also GG1 Mitglied von GG2, diese wiederum Mitglied in GG3 ist und GG2 gelöscht wird, verschwinden ebenfalls die Gruppenzugehörigkeiten. Auch hier werden beim wiederherstellen der GG2 aus dem AD-Papierkorb, die Gruppenzugehörigkeiten und somit das Forward- und Back-Link automatisch wiederhergestellt.
Weitere Informationen:
2.175 Attribute msDS-DeletedObjectLifetime
2.109 Attribute isDeleted
2.112 Attribute isRecycled
2.179 Attribute msDS-EnabledFeature
The Active Directory database garbage collection process
Useful shelf life of a system-state backup of Active Directory
Viewing deleted objects in Active Directory
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)
-
-
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 Update Sequence Number (USN)
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.
Einen Tombstone wiederbeleben
Das wiederbeleben eines Tombstones hat gegenüber einem neu erstellen eines Benutzer-Objekts einen großen Vorteil.
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.
Des Weiteren ist es auch nicht notwendig, wie bei der autoritativen Wiederherstellung, den DC offline zu schalten.
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.
Tipp: Genau an dieser Stelle, setzt das Skript Werding an.
Durch das vierte Bit im Search-Flags Attribut (in Dezimal 8) allerdings, lassen sich weitere Attribute im Tombstone speichern.
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.
Damit ein Tombstone zum Leben erweckt werden kann, muss zum einen das Attribut Is-Deleted regelrecht entfernt werden
(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.
Diese wären unter anderem:
- Das Benutzerkonto mit dem das Objekt wiederhergestellt werden soll, muss über das Recht des Wiederbelebens eines Tombstone verfügen
- Natürlich kann der Benutzer nicht sein eigenes Benutzer-Objekt wiederherstellen
- Das Attribut Is-Deleted des Objekts muss auf den Wert TRUE gesetzt sein
Um einen Tombstone wiederzubeleben, lässt sich das z.B. mit ADRestore (einem Kommandozeilen-Tool aus dem Hause Microsoft)
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:
Damit eine OU autoritativ wiederhergestellt werden kann, müssen folgende Schritte durchgeführt werden:
-
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“,
dass Kommando „restore object DN“ verwendet werden.
Weitere Informationen:
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
Sichern mit Images ist bei vielen sehr gern gesehen, da man sich damit "scheinbar" gegen einen Crash schützen kann (oder vor einer Änderung).
Was bei einem Client evtl. noch zutrifft, trifft bei einem DC, Exchange oder SQL ... etc. schon gar nicht zu.
Daher mein Appell an alle:
Bitte lasst die Finger von Images auf DCs und Systemen die mit transaktionalen Datenbanken arbeiten.
Warum kann man DCs nicht imagen ?
Wegen der Active Directory Datenbank.
Nur bei einer Onlinesicherung, kann die Konsistenz der Datenbanken geprüft werden. Mit Images
sichert man womöglich wochenlang eine defekte Datenbank mit und steht im Disasterfall dann ohne Backup da.
Würde man diese aber online sichern, so würde das System die Inkonsistenz im Form einer Warnung/Fehlermeldung melden.
Was wäre zum Beispiel, wenn auf der Festplatte ein Bad Sector/Block existieren würde ?
Eine Exchange oder SQL Datenbank kann ziemlich groß werden, daher ist es möglich, dass der Bad Block damit die Datenbank inkonsistent werden lässt.
Was bei einem Offline-Image nicht auffällt, würde stattdessen bei einer Online-Sicherung sehr wohl auffallen.
Windows bemerkt aufgrund der Differenz zwischen den während der Sicherung kalkulierten Prüfsummen und den beim ursprünglichen Schreiben kalkulierten Prüfsummen, daß hier ein Datenverlust seit der letzten erfolgreichen Onlinesicherung eingetreten ist.
Wird das Image online erstellt, dramatisiert sich das ganze noch mehr.
Was ist zum Beispiel, wenn eine Datei sich über Eintausend Sektoren verteilt und das Imaging-Programm sichert von Sektor 1 bis 1000.
Es ist gerade bei Sektor 250, da wird die Datei erneut im laufenden Betrieb beschrieben.
Das Imaging-Programm bekommt davon nichts mit. Somit wird dann Sektor 1-250 von der alten Version und 251 bis 1000 von der neuen Version ins Image geschrieben.
Dann kommt noch der Aspekt der Computerkontokennwörter hinzu.
Denn unter Windows NT wird standardmäßig das Computerkontokennwort alle 7 Tage und unter Windows 2000/XP/Vista alle 30 Tage geändert.
Wird nun ein älteres Image zurückgesichert, können sich die Clients nicht mehr an der Domäne anmelden. Denn bei der Erstellung
des Server-Images werden natürlich auch die Computerkontokennwörter mit gesichert.
Hier ist ein schöner Artikel, den sich jeder mal zu Herzen nehmen sollte (Stichwort: USN-Rollback):
Warum Images nicht als Datensicherung taugen
Dieser sollte auch nicht fehlen:
http://www.msexchangefaq.de/verschiedenes/imagebackup.htm
Ein USN-Rollback unter Windows 2000:
http://support.microsoft.com/kb/885875/en-us
Ein USN-Rollback unter Windows 2003:
http://support.microsoft.com/kb/875495/en-us
Das sichern des System State (Systemstatus) ist das mindeste,
was ein Administrator auf seinen Domänencontrollern sichern sollte, wenn nicht sogar "muss".
Denn dadurch kann man z.B. bei einem Servercrash in einer Domäne, in dem bloß ein einziger Domänencontroller existiert,
sich die „Domäne“ samt Active Directory rücksichern und braucht somit nicht erneut jeden User einzeln anlegen oder die Computer
aus der „alten“ Domäne zu entfernen und in die neue einzubinden. Alleine wegen der Ausfallsicherheit ist es empfehlenswert,
in jeder Domäne min. zwei DCs zu installieren. Der zweite DC könnte auch (wegen finanziellen Engpässen) auf eine
„ältere“ Client-Maschine installiert werden.
Weitere Informationen erhalten Sie unter: Wie stelle ich das AD wieder her?
Neben der Sicherung des System States, sollte natürlich ein Disaster-Recovery, Backup Konzept und ein Notfallplan
existieren und vor allem auch regelmäßig an die aktuellen Gegebenheiten angepasst werden.
http://www.microsoft.com/technet/community/events/windows2003srv/tnt1-94.mspx
Für Exchange:
http://www.microsoft.com/technet/prodtechnol/exchange/2003/library/disrecopgde.mspx
Mit sichern des System States werden folgende Dateien gesichert:
- Die Active Directory Datenbank – NTDS.DIT
- SYSVOL
- Systemstart Dateien
- Registry
- COM+
Falls eine CA installiert wäre, dann auch diese.
Man sollte und muss auf das Alter des System States beim rücksichern achten, genauer auf das Alter des Attributs „TombstoneLifetime”.
Die Sicherung des Systemstatus darf nicht älter als der eingestellte Wert sein.
Den eingestellten Wert der „TombstoneLifetime“ kann man sich mit ADSIEdit
(aus den Windows Support Tools) im folgenden Pfad anschauen:
CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=Root-Domäne,DC=TLD
Dort findet man in den Eigenschaften des Containers CN=Directory Service das Attribut tombstoneLifetime.
Ist dort ein Wert gesetzt, beträgt die Tombstone Lifetime (TSL) den eingetragenen Wert in Tagen.
Steht im Attribut als Wert hingegen <Not Set>, so beträgt die TSL den Standardwert von 60 Tagen.
Die TSL wird mit dem installieren des allerersten DCs in einer Gesamtstruktur und zwar für alle
Domänen festgelegt. Dieser Wert kann nicht pro Domäne konfiguriert werden. Er lässt sich aber manuell verändern.
Die TSL beträgt unter:
- Windows 2000 (mit allen SPs) = 60 Tage
- Windows Server 2003 ohne SP = 60 Tage
- Windows Server 2003 mit Service Pack 1 = 180 Tage
- Windows Server 2003 R2 (mit SP1) = 60 Tage
- Windows Server 2003 mit Service Pack 2 = 180 Tage
- Windows Server 2003 R2 ab Service Pack 2 = 180 Tage
- Windows Server 2008 = 180 Tage
- Windows Server 2008 R2 = 180 Tage
Siehe folgenden Artikel: Das Geheimnis der Tombstone Lifetime
Angenommen man hätte einen Festplatten - Crash in einem Domänencontroller der der einzigste DC der Domäne wäre,
dann gilt es den Server zu reparieren, in Form von Festplatten tauschen und anschließend neu installieren des Betriebssystems
„Windows Server 2003 R2“. Dabei spielt es keine Rolle welchen Computernamen sowie IP - Einstellungen man dem Server vergibt,
denn nach dem rücksichern des System State, bekommt der Server die Daten, die er beim sichern des System State hatte.
Nach dem installieren des Betriebssystems gilt es danach das Betriebssystemeigene Sicherungsprogramm „NTBACKUP“
über „Start - Ausführen - Ntbackup“ zu starten und eine Rücksicherung des System States zu starten (ausgegangen davon,
dass man das SYSTEM STATE über das NTBACKUP sichert). Dabei ist es auch egal auf was gesichert
wurde und welchen Laufwerksbuchstaben das Sicherungslaufwerk hatte.
Nach dem rücksichern und anschließendem neu starten des Servers fehlen die Active Directory - Snap - Ins
wie z.B. Active Directory Benutzer- und Computer oder „Standorte und Dienste“ etc. unter „Start - Programme - Verwaltung“.
Nun könnte man mit „Start - Ausführen - dsa.msc“ (für AD- Benutzer- und Computer) oder dssite.msc (für AD-Standorte- und Dienste)
die Snap - Ins aufrufen. Eine andere Alternative wäre, dass man sich selbst eine MMC erstellt und diese
ganzen Snap-Ins dort hinzufügt und speichert. Wer das alles nicht will und den gewohnten „Standard“ haben möchte,
sprich, die ganzen Snap-Ins unter „Start - Programme - Verwaltung“ haben möchte, der installiert sich das „Adminpack.msi“
aus %systemroot\system32\ und bekommt anschließend das gewohnte Bild unter „Start - Programme -Verwaltung“.
Zum Schluss müsste noch das DNS sowie DHCP installiert und konfiguriert werden.
Es gibt auch eine Möglichkeit, dass DCPROMO mit dem Schalter „/ADV“ auszuführen. Das wäre für den Fall ideal,
wenn man z.B. einen weiteren Server zum Domänencontroller promoten möchte, dieser aber an einem Standort mit einer
geringen Anbindung steht. Damit eben nicht die komplette Active Directory - Datenbank repliziert werden muss, sichert
man an einem bestehenden DC der Domäne, zu der der neue Server als weiterer DC heraufgestuft wird, dass System State
und kopiert dieses auf eine externe Fesplatte oder CD/DVD. Damit stuft man dann den neuen Server zum DC und anschließend
muss dann nur noch die Änderung seit der erstellten System State Sicherung repliziert werden.
Weitere Inforamtionen:
Domänencontroller-Installation von einer Sicherung
Install from Media
|
Copyright © 2010 Yusuf Dikmenoglu. All rights reserved.
DasBlog 'Portal' theme by Johnny Hughes.
Pick a theme:
|
|