Windows Server 2008 R2 Recycle Bin und “linked attributes”

Hi, hier ist wieder Florian, einer der deutschen MVPs – diesmal mit einem Active Directory-Thema als Gastbeitrag (*) für den Domain Team Blog. Nicht, dass ich mit den Gruppenrichtlinien-Themen zu einseitig werde ;-)

Nachdem das nordamerikanische AD Team um Ned Pyle (https://blogs.technet.com/askds/) einen klasse Artikel zum Thema AD Recycle Bin (https://blogs.technet.com/askds/archive/2009/08/27/the-ad-recycle-bin-understanding-implementing-best-practices-and-troubleshooting.aspx) verfasst hat, möchte ich die Gelegenheit ergreifen, um ein wenig tiefer in die Speicherung von Grabstein- und gelöschten Objekten einsteigen. Speziell soll uns ein Thema beschäftigen: Wie werden Gruppenmitgliedschaften (oder andere verknüpfte Attribute) behandelt, wenn ein Objekt gelöscht wird und wie verhält sich Active Directory mit aktiviertem Recycle Bin im Vergleich zu einem nicht aktivierten Recycle Bin?

Um die Materie genau verstehen zu können, hier ein wenig Theorie: Active Directory kennt neben Attributen mit Zeichenketten oder Binärdaten auch Attribute, die auf andere Objekte im Verzeichnis verweisen – das sind „linked attributes“. Linked attributes werden in einer separaten Tabelle innerhalb der Active Directory-Datenbank gespeichert und vom Verzeichnis speziell behandelt. Wer bereits ausgiebig über „linked attributes“ gelesen und gehört hat, darf einen Absatz überspringen, was jetzt folgt, ist das klassische Beispiel zu Active Directory-Gruppenmitgliedschaften, das die Verknüpfung bestens beschreibt:

Um die Gruppenzugehörigkeit von Sicherheitsprinzipalen in Active Directory speichern zu können, stellt Active Directory eine Verbindung zwischen den Objekten her. Gehört ein Benutzer einer Gruppe an, wird die Gruppenmitgliedschaft des Benutzers im Attribut „memberOf“ gespeichert – die Gruppe führt diese Mitgliedschaft im Attribut „member“. Wird in den Eigenschaften des Benutzers die Gruppemitgliedschaft beendet, verschwindet wie aus Geisterhand auch der Eintrag der Gruppenmitglieder aus den Eigenschaften der Gruppe. Schuld daran ist die Attributverknüpfung, die Active Directory zwischen „member“ und „memberOf“ führt. Diese Verknüpfung besteht aus zwei „links“, einem Forward- und einem Backlink. Gesteuert wird die Verknüpfung nur durch den Forwardlink, da Active Directory das Schreiben auf nur einen der beiden Links gestattet.  Backlinks werden „on the fly“ vom Verzeichnis anhand der Forwardlink-Informationen berechnet. Im Falle der Attribute „member“ und „memberOf“ ist „member“ (das Attribut der Gruppe) der schreibbare Forwardlink und „memberOf“ der kalkulierte Backlink. Wird ein Benutzer einer Gruppe hinzugefügt, wird ein neuer Forwardlink in die Gruppe eingefügt, was in einem Eintrag in die Linktabelle resultiert. Wird ein Benutzer aus einer Gruppe gelöscht, wird der Forward-Link aus der Link-Tabelle gelöscht.

Abbildung 1: Forward- und Backlink zweier Attribute. Nur Forwardlinks können geschrieben werden.

„Member“ und „MemberOf“ sind nicht die einzigen linked attributes im Verzeichnis – weitere bekannte Beispiele sind „Manager“ und „directReports“ oder „managedBy“ und „managedObjects“.

Was passiert nun, wenn ein Benutzer – ohne dass der Recycle Bin aktiviert ist – gelöscht wird? Alle Attribute werden im Zuge der Attributbereinigung für die Tombstoneerstellung gelöscht – selbstverständlich auch verlinkte Attribute. Da das Benutzerkonto Backlinks besitzt, müssen die Verknüpfungen am Forwardlink gelöscht werden – etwa der Gruppe. Anschließend wird das Objekt als gelöscht markiert und in den „Deleted Objects“-Container verschoben. Stellt man den Benutzer mit Hilfe eines Restores wieder her, erhält der Benutzer alle Attribute gemäß des letzten Backups zurück – mit Ausnahme der verknüpften Attribute, die dem Benutzer nur als backlink zur Verfügung stehen. Da die Gruppenmitgliedschaft mit der Gruppe gespeichert wird, kann die Wiederherstellung die Gruppen nicht zurückspielen – klar, wir haben ja nur den Benutzer wiederhergestellt. Die logische Konsequenz wäre also sowohl den Benutzer als auch seine Gruppen zurückzuspielen. Gut, dass seit Windows Server 2003 SP1 beim Restore durch NTDSUtil  eine LDIF-Datei erstellt wird, die beim Import mit LDIFDE nicht wiederhergestellte Backlinks des Benutzers zurückimportiert. Und so, ohne Restore der Gruppen, Mitgliedschaften zurückspielt.

Mit Windows Server 2008 R2 und dem AD-Papierkorb sieht das viel einfacher aus: wird ein Benutzer gelöscht, erhält das Objekt die Löschmarke und wird ebenfalls in den „Deleted Objects“-Container verschoben. Anders als bei nicht aktiviertem Recycle Bin werden alle Attribute des Objekes beibehalten – für die Zeit, in der es ein „Deleted Object“ ist und nicht in die „Recycled Object“-Phase übergeht.

Der Beispielbenutzer „Thomas“ wird verwendet, der Mitglied der Administratoren von Contoso ist und einige Gruppenmitgliedschaften besitzt.

Wird Thomas gelöscht und danach mit LDP im „Deleted Objects“-Container betrachtet, zeigt sich etwa dieses Bild:

Abbildung 2: LDP zeigt das Attribut „memberOf“ nicht an

Das Attribut „memberOf“ taucht in der Liste der Attribute des gelöschten Benutzerkonto von Thomas nicht auf - und das, obwohl der Recycle Bin aktiviert ist und alle weiteren Attribute vorhanden sind und nicht bereinigt wurden. Auch aus den vorherigen Gruppen wurde Thomas entfernt:

Abbildung 3: Thomas ist nicht mehr in der Gruppe IT-Admins

LDP ist normalerweise bekannt dafür, Objekte und Attribute anzuzeigen, die sonst kein anderes Tool anzeigt – es verheimlicht eigentlich keine Objekte. Wie ist das möglich? Eventuell weiß ja die PowerShell etwas dazu. Der Befehl

C:\ PS> Get-AdObject –filter {givenName –eq „Thomas“} –SearchBase „CN=Deleted Objects,DC=contoso,DC=com“ –IncludeDeletedObjects –Properties *

liefert uns alle Objekte aus dem Start-Suchcontainer “Deleted Objects”, deren Vorname “Thomas” lautet. In der Tat findet PowerShell den gelöschten Thomas:

Abbildung 4: PoSH findet Thomas

Zu unserem Erstaunen mit dem memberOf-Attribut und den korrekten Gruppen! Will Microsoft uns nun endgültig zwingen, die PowerShell zu nutzen und liefert mit anderen Tools absichtlich unvollständige Ergebnisse? Bevor Verschwörungstheorien die Runde machen und sich böswillige Absichten herumsprechen, wollen wir das Geheimnis lüften:

Um verlinkte Attribute – nicht nur das Linkpaar "member" und "memberOf" – bei einem Restore wiederherstellen zu können, dem Benutzer aber trotzdem aktuelle AD-Daten anzeigen zu können und gelöschte Objekte aus den grafischen Oberflächen zu entfernen, bedient sich Active Directory eines Trick: Verknüpfungen zu gelöschten Objekten werden deaktiviert. Durch die Markierung des Forwardlinks des Attributes als „deaktiviert“ werden Verknüpfungen zwischen Objekten nicht mehr in den üblichen GUIs angezeigt – per Standard auch nicht in LDP. Die PowerShell ist so eingestellt, dass sie deaktivierte Verknüpfungen automatisch verfolgt, berechnet und automatisch mit anzeigt.

Ganz hilflos ist man mit LDP aber auch nicht: wer sich die deaktivierten Links mit LDP anzeigen lassen will, muss zuvor ein seit 2008 R2 mitgeliefertes LDAP-Control per „Optionen“ – „Steuerelemente“ aktivieren. Controls sind Serveranweisungen, die LDAP-Clients an den LDAP-Server, in unserem Fall Active Directory, schicken können, um beispielsweise den Ergebnissatz der Abfrage zu manipulieren oder Sucheinstellungen zu konfigurieren.

Das Control für die verlinkten Attribute heißt treffend „Return deactivated links“.

Ist das Steuerelement zu den aktiven Control hinzugefügt worden, klappt es auch mit LDP:

Das „memberOf“-Attribut wird nun auch korrekt für Thomas angezeigt und das Ergebnis deckt sich mit der Ausgabe unseres "Get-ADObject"-Befehls der PowerShell.

Bevor wir es vergessen, ein Hinweis zu einer kleinen Stolperfalle zum Schluss: schließt und öffnet man LDP, merkt es sich die zuletzt aktivierten Controls. Da „Return deactivated links“ ein neues Control in Server 2008 R2 ist, verstehen Domänencontroller vor R2 dieses Steuerelement nicht, wenn man sich mit ihnen verbindet und durch das Verzeichnis browsen will. Die Fehlermeldung sieht dann so aus:

„Error processing control“ ist das Stichwort. Um LDP wieder wie gewohnt mit prä-2008R2-DCs nutzen zu können, muss das Control im oben genannten Menü deaktiviert werden.

Ich hoffe ich konnte mit diesem Blog-Beitrag nützliche Informationen zur Verfügung stellen und dem ein oder anderen eine böse Überraschung im Umgang mit gelöschten Objekten und dem Papierkorb ersparen. Besten Dank an dieser Stelle an Wolfang Sauer, der mir half, das „Verhalten“ in meinem Kopf richtig zu verstehen. Bis zum nächsten Mal!

Cheerio,
Florian

* Rechtlicher Hinweis: Bei den hier als "Gastbeitrag" markierten Artikeln handelt es sich um Blogs, die von nicht-Microsoft Mitarbeitern verfaßt wurden. Diese Beiträge geben ausschließlich die Meinung des jeweiligen Autors wieder und stimmen nicht unbedingt mit der Meinung von Microsoft überein. Microsoft macht sich diese Beiträge ausdrücklich nicht zu eigen. Eine Vorabkontrolle der Beiträge findet nicht statt. Dementsprechend kann Microsoft keine Verantwortung oder Gewähr für die Beiträge übernehmen.