Gruppengeheimnisse

Ich habs mal so genannt, weil das stellenweise etwas verworren ist, was in Active Directory da mit member, memberOf, primaryGroup und so abgeht, und überhaupt Gruppen in den Systemen nur auf den ersten Blick einfach aussehen. Und weil ich es mir zum 3. Mal schon herleiten musste, hab ich’s jetzt mal aufgeschrieben.

Wieso ich meine, dass Gruppen etwas verwirrend sind? Machen wir mal folgendes Experiment: Wir erzeugen einen neuen Benutzer, nennen wir ihn mal USER1. Wir erzeugen auch eine neue Gruppe, die nennen wir -richtig! – GROUP1. Zusätzlich zu den Domänen-Benutzern, in denen USER1 ja automatisch Mitglied wird, packen wir ihn auch noch in GROUP1. In ADUC (Active Directory Users and Computers bzw. Benutzer und Computer) schauen wir uns bei den Eigenschaften von USER1 den Reiter „Mitglied von“ an und finden wie erwartet zwei Einträge, „Domänen-Benutzer“ und „GROUP1“. Bei „GROUP1“ unter „Mitglieder“ finden wir den „USER1“ ebenfalls wie erwartet wieder, und bei der Gruppe „Domänen-Benutzer“? Auch hier taucht er auf. Soweit alles wie erwartet.

Wenn man das jetzt erst mal so interpretiert, dann sollte das Benutzer-Objekt USER1 also im Attribut „memberOf“ zwei Einträge haben, und die Gruppen „Domänen-Benutzer“ und GROUP1 jeweils im Attribut „member“ den USER1. Da stellt sich die Frage: Wieso kommt es da nicht irgendwann mal zu Inkonsistenzen, also widersprüchlichen Einträgen?

Schauen wir uns die drei Objekte doch mal mit adsiedit an (oder mit anderen LDAP-Browsern, hauptsache nicht mit ADUC). Da finden wir ganz merkwürdige Dinge, die mit der obigen Anzeige nichts mehr zu tun haben:

Objekt Attribut Bemerkung
USER1 memberOf Das Attribut gibt es gar nicht (je nach Einstellung des LDAP-Browsers)!
Domänen-Benutzer member Das Attribut gibt es zwar, aber da steht kein USER1 drin!
GROUP1 member Es steht wie erwartet der USER1 drin

Da stellt sich doch die Frage: Woher weiß das System denn dann, dass USER1 in Domänen-Benutzer ist? Weder beim Benutzer-Objekt noch beim Gruppenobjekt scheint das zu stehen. Die Antwort: Es steht schon beim Benutzerobjekt, aber das Attribut heißt anders, nämlich „primaryGroupID“ und ist ein Integer-Wert. Die Gruppe Domänen-Benutzer wiederum hat das Attribut „primaryGroupToken“ mit dem gleichen Wert, und alle Benutzer, die die Gruppe als Primäre Gruppe haben, haben die primaryGroupID gesetzt und tauchen in der „member“-Liste der Gruppe nicht nochmal auf. In der „member“-Liste tauchen nur die Benutzer auf, die zwar in der Gruppe sind, bei denen diese Gruppe aber nicht die primäre Gruppe ist (auf dem Reiter „Mitglied von“ bei Benutzerobjekten taucht das mit der primären Gruppe übrigens auch auf, nur falls sie sich schon mal gefragt haben, was das soll…). Letzeres erklärt auch, warum in GROUP1 der USER1 in „member“ drinsteht: Das ist nicht seine primäre Gruppe!

Und was ist mit dem fehlenden Attribut memberOf? Nun, es handelt sich dabei um einen sog. „Backlink“, ein dynamisch erzeugtes Attribut, das zum Zeitpunkt der Abfrage gefüllt wird. Je nachdem, mit welchem LDAP-Browser sie eine Suche durchführen, wird es angezeigt oder nicht. LDP zum Beispiel zeigt es an, und die adsiedit-Version von Server 2008 erlaubt das Zuschalten von Backlinks (via Filter). Das System durchsucht übrigens nicht jedes mal alle Gruppen, um das memberOf zu erzeugen, die DCs halten eine Tabelle vor, in der die Zuordnung abgefragt werden kann.

Fassen wir mal bis hier zusammen:

Beim Benutzerobjekt findet sich nur das Attribut „primaryGroupID“, sonst findet sich hier keinerlei Gruppenzugehörigkeit!

Bei Gruppen finden sich im Attribut „member“ (multivalued logischerweise) nur die Benutzerobjekte wieder, die diese Gruppe nicht als primäre Gruppe haben. Weiterhin hat jede Gruppe noch ein Attribut „primaryGroupToken“, dessen (Integer)-Wert mit dem Attribut „primaryGroupID“ bei Benutzern übereinstimmt.

Damit ADUC also die Mitgliederliste von Gruppen so wie oben beobachtet anzeigen kann, sucht es

  • alle Benutzer, die bei der Gruppe im „member“-Attribut drinstehen (übrigens als DN).
  • alle Benutzer, die unter „primaryGroupID“ den gleichen Wert haben wie die der Gruppe in „PrimaryGroupToken“

und zeigt diese Kombination an. Bei Benutzern wird die Gruppenzugehörigkeit ermittelt aus

  • der „primaryGroupID“, für die es ein Gruppenobjekt mit identischem „primaryGroupToken“ geben muss
  • allen Gruppen, in denen der Benutzer-DN im Attribut „member“ auftaucht.

Da insbesondere die letzte Abfrage langwierig sein kann, führen die DCs wie oben schon erwähnt eine entsprechende Tabelle, entnehmen dieser die relevanten Informationen und erzeugen ein Backlink-Attribut namens „memberOf“ mit den Gruppen-DNs aller Gruppen außer der primären Gruppe.

Ein kurzer Seitenblick auf die Linux-Welt: Dort wird das mit den primären Gruppen genauso gemacht. In der Passwort-Datei (/etc/passwd) findet sich nach der uidnumber die gidnumber der primären Gruppe, sonst keine Gruppeninformationen. Die ist in einer weiteren Datei (/etc/groups) hinterlegt. Dort steht pro Zeile eine Gruppe. Vorne die gidnumber der Gruppe, und dahinter alle Benutzer, die in dieser Gruppe sind, auch hier üblicherweise ohne die Benutzer, die die Gruppe als primare Gruppe haben. Auch das mit den Backlinks wird von OpenLDAP-Servern ähnlich gehandhabt.

Und das ganze erklärt jetzt auch, warum es nicht zu Inkonsistenzen kommt: Die Gruppen-Informationen sind gar nicht doppelt eingetragen, lediglich das Frontend gaukelt uns das vor. Dass es dennoch zu Widersprüchen kommen kann, ist ein anderes Thema und hat was mit Desaster Recovery zu tun, soll uns aber hier grad nicht interessieren…

Advertisements

Über Ralf Wigand

...arbeitet für Microsoft und war von 2008-2015 MVP für Directory Services.
Dieser Beitrag wurde unter Active Directory, LDAP abgelegt und mit , , , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

2 Antworten zu Gruppengeheimnisse

  1. Pingback: gidnumber im Active Directory | Mathom

  2. Anna-Luise schreibt:

    Super Post. Würde gern mehr Posts zu dem Thema sehen. Ich freue mich schon auf die naechsten Posts.

Kommentar verfassen

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s