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.