Active Directory: Objekte differenziert auflisten

Dieser Beitrag erschien zuerst in Ralfs Blog.

In einem Standard-AD sieht man bei Objekten drei verschiedene Leserechte, nämlich

• List Child (LC)
  regelt die Sichtbarkeit von Objekten unterhalb des aktuellen Objektes, also zum Beispiel den Inhalt einer OU
• Read Control (RC) bzw. Read Permissions 
  regelt die Lesbarkeit von Besitzer, primärer Gruppe und der DACL (nicht der SACL)
• Read Property (RP)
  kontrolliert die Lesbarkeit der Eigenschaften eines Objektes. Fehlt einem Benutzer beispielsweise dieses Recht, dann weiß er nicht, um welche Art von Objekt es sich handelt (genauer gesagt um welche Objektklasse) , und Tools wie “Active Directory Users and Computers” können das Objekt nur mit einem neutralen Icon darstellen.

Genau genommen gibt es aber noch ein viertes Leserecht, nämlich “List Object” (LO). Dieses Recht wird aber standardmäßig nicht angezeigt. Um seine Bedeutung zu verstehen, hier zunächst ein kleines Beispiel:

Wir denken uns eine OU namens “ORGA”. Diese OU enthält drei weitere Unter-OUs, nämlich “PERSONAL”, “TECHNIK” und “SERVICE”. In einem Standard-AD sieht ein Benutzer, der für die OU “ORGA” die drei oben genannten Rechte hat, auch alle drei darunter liegenden OUs, selbst wenn er auf eine der OUs gar keine weiteren Rechte hat. Ein Benutzer “techniker1”, der lediglich auf die OU “TECHNIK” lesend zugreifen können soll, benötigt, damit er die OU überhaupt sieht, das “List Content”-Recht für die darüber liegende OU “ORGA”. Mit diesem Recht sieht er aber auch die beiden OUs “PERSONAL” und “SERVICE”, obwohl er dort gar keine Rechte hat. Es wäre schön, wenn der Benutzer “techniker1” auch nur die OU “TECHNIK” sehen könnte, obwohl es in unserem Beispiel nicht schlimm ist, wenn er auch die anderen OUs sieht. Es mag aber Fälle geben, wo das nicht erwünscht ist, zum Beispiel beim Hosting verschiedener Kunden in einem gemeinsamen AD. Dies ist im Standard-Modus des AD nicht möglich. Hierzu muss man etwas tiefer einsteigen und sich die beiden Sichtbarkeitsmodi des AD anschauen (von deren Existenz die meisten keine Ahnung haben):

• “List Child”-Modus
• “List Object”-Modus

“List Child”-Modus

Dies ist die Standard-Einstellung im AD. Hat ein Benutzer das “List Child”-Recht auf der “ORGA”-OU, so sieht er alle drei darunter liegenden Unter-OUs. Dabei spielen Rechte, die er auf den Unter-OUs selbst hat, keinerlei Rolle.

“List Object”-Modus

Dies ist (logischerweise jetzt) nicht die Standard-Einstellung im AD. Um in diesem Modus noch Unter-OUs sehen zu können, braucht der Benutzer das “List Object”-Recht auf der “ORGA”-OU und auf jeder der Unter-OUs, die er sehen können soll. Das “List Child”-Recht der “ORGA”-OU spielt in diesem Modus keine Rolle!

Soll also der Benutzer “techniker1” nur seine OU “TECHNIK” sehen können, dann muss ihm bei aktiviertem “List Object”-Mode das “List Object”-Recht auf die OUs “ORGA” und  “TECHNIK” erteilt werden und bei den OUs “PERSONAL” und “SERVICE” entzogen werden (sofern gesetzt).

Wie aktiviert man aber diesen “List Object”-Modus?

Das ist eine forestweite Einstellung, die sich im “Configuration”-Container befindet, genauer gesagt im Objekt “CN=Directory Services, CN=Windows NT,CN=Services”. Wie man dorthin findet, schreibe ich hier mal nicht extra, wer sich schon so tief ins AD reingekämpft hat, dass er über den “List Object”-Modus nachdenkt, der wird schon wissen, mit welchen Tools er den Configuration-Container bearbeiten kann …

Das fragliche Attribut heißt dann übrigens “dSHeuristics” und ist auch noch für andere forestweite Eigenschaften zuständig. Warum die AD-Entwickler hier nicht einzelne Attribute genommen haben, kann mir mal bei Gelegenheit jemand erklären. Jedenfalls wird der Wert dieses Attributes (weil vom Typ Unicode String) als Zeichenkette und nicht als Zahl gelesen. An der dritten Stelle von links (nicht lachen!) muss eine “1” stehen, um den “List Object”-Modus zu aktivieren. Ist das Attribut also leer, dann muss die Zeichenkette “001” eingetragen werden (nicht einfach nur eine “1”!). Steht schon was drin, sagen wir “0000002”, dann muss das geändert werden auf “0010002” usw.

Sobald die Konfiguration repliziert wurde, ist der “List Object”-Modus aktiv.

Hinweis (oder Warnung?): Die geänderte Sichtbarkeit hat eine offensichtliche Nebenwirkung: Bei jedem Zugriff auf ein Container-Objekt wie OUs muss der DomainController jetzt nicht wie früher nur ein Recht überprüfen (nämlich das “List Content”-Recht der OU selbst), sondern das “List Object”-Recht der OU und aller darin  liegenden Objekte! Die Antwortzeiten können also durchaus spürbar länger werden. Allerdings setzt sich eine Antwortzeit ja zusammen aus der Zeit zur Ermittlung (Enumeration) der zurückzuliefernden Objekte plus der Zeit für den Netzwerktransport (und genau genommen plus der Aufbereitungszeit durch den Client), und da bei sinnvoll verwendeten Rechten meist deutlich weniger Objekte zurückgeliefert werden, tritt die Verzögerung oft nicht so deutlich zu Tage wie man befürchten könnte.

So. Alles klar? Na dann viel Spaß!