Eine Gruppe im Active Directory hat drei Einträge. Die Anwendung liest das Attribut member, findet drei Personen und ist fertig. In Wahrheit gehören sieben Menschen dazu, denn zwei der drei Einträge sind selbst Gruppen. Niemand bemerkt den Fehler, bis eine Richtlinie bei vier Personen nicht greift.
Das Problem mit member
Das Attribut member einer Gruppe listet ihre unmittelbaren Mitglieder: Benutzer, Kontakte, Computer und andere Gruppen. Es löst nichts auf. Verschachtelung ist in gewachsenen Verzeichnissen die Regel, etwa Abteilungsgruppen in Standortgruppen in einer Gruppe für alle Beschäftigten.
Die Kettenregel im Active Directory
Active Directory kennt eine eigene Vergleichsregel für Ketten, LDAP_MATCHING_RULE_IN_CHAIN mit der Kennung 1.2.840.113556.1.4.1941. Sie verfolgt eine Verknüpfung über beliebig viele Stufen.
Alle Benutzer, die direkt oder indirekt Mitglied einer Gruppe sind:
ldapsearch -H ldaps://dc1.firma.local -b "DC=firma,DC=local" \ "(&(objectCategory=person)(objectClass=user)(memberOf:1.2.840.113556.1.4.1941:=CN=Aussendienst,OU=Gruppen,DC=firma,DC=local))" \ mail displayName
Umgekehrt liefert dieselbe Regel auf member alle Gruppen, in denen ein Benutzer direkt oder indirekt steckt. Für einen einzelnen Benutzer ist das berechnete Attribut tokenGroups schneller, es wird mit Suchbereich base am Benutzerobjekt gelesen.
In PowerShell erledigt Get-ADGroupMember -Identity Aussendienst -Recursive dasselbe.
Drei Fallen
Große Gruppen
Hat eine Gruppe mehr Mitglieder, als der Domänencontroller in einer Antwort liefert, standardmäßig 1500, bleibt member unvollständig. Der Rest kommt über den Bereichsabruf mit member;range=0-1499, danach member;range=1500-2999 und so weiter, bis die Antwort mit einem Stern endet. Die Kettenregel im Filter umgeht das, weil sie Benutzer sucht statt Werte zu lesen.
Die primäre Gruppe
Benutzer, deren primaryGroupID auf eine Gruppe zeigt, stehen nicht in deren member. Bei Domänen-Benutzer betrifft das in der Regel alle. Auch die Kettenregel findet sie nicht. Wer primäre Gruppen braucht, sucht zusätzlich nach primaryGroupID mit der RID der Gruppe.
Mitglieder aus fremden Domänen
Mitglieder aus einer vertrauten Gesamtstruktur erscheinen als Objekte unter ForeignSecurityPrincipals mit ihrer SID. Ihre Adresse steht im anderen Verzeichnis.
OpenLDAP und verwandte Verzeichnisse
Die Kettenregel ist eine Eigenheit von Active Directory. OpenLDAP, 389 Directory Server und verwandte Verzeichnisse kennen sie nicht. Auch das Overlay memberof liefert dort nur direkte Mitgliedschaften.
Die Auflösung geschieht deshalb im Client:
- Gruppe lesen, Einträge aus
memberoderuniqueMembersammeln. - Jeden Eintrag prüfen: Person übernehmen, Gruppe in die Warteschlange.
- Bereits besuchte Gruppen merken, damit Kreise nicht endlos laufen.
Zwei Befunde aus dem Labor: Der Bereichsabruf member;range=0-* ist eine Eigenheit von Active Directory. OpenLDAP antwortet darauf mit einem leeren Attribut, ohne Fehler, und jede Gruppe hat plötzlich null Mitglieder. Und wer eine Gruppe über ihre GUID sucht, muss die Anzeigeform umrechnen: Die ersten drei Felder stehen in der Binärform in umgekehrter Bytefolge.
Wo das zählt
Überall, wo Gruppen über Rechte und Regeln entscheiden: Lizenzen je Gruppe, Richtlinien für Verschlüsselung, Signaturvorlagen je Abteilung. Eine unvollständige Auflösung fällt dort nicht als Fehler auf, sondern als Person, bei der eine Regel nicht greift.
Wie Conbool das löst
Der Verzeichnis-Agent von Conbool löst Gruppen im Active Directory mit der Kettenregel im Server auf und geht in anderen LDAP-Verzeichnissen die Kette selbst ab. Im Labor ergab eine Gruppe mit drei direkten Einträgen sieben Personen, bis in die Datenbank. Mehr auf der Seite E-Mail-Sicherheit ohne Entra ID und in der Doku zu Gruppen.
