Die Primary Group in Active Directory

Es gibt einen Mechanismus in Active Directory, den man normalerweise nie braucht. Leider wissen viele Administratoren das nicht und setzen den Mechanismus ein, was oft zu unerwünschten Reaktionen führt. Das Dumme daran: Es können daraus durchaus Sicherheitsprobleme entstehen.

Die Rede ist von den Primary Groups (im Deutschen: Primäre Gruppe). Für jedes Benutzerobjekt kann man genau eine Primary Group festlegen, in der grafischen Oberfläche findet sich dies auf der Seite “Mitglied von” eines Benutzerobjekts im unteren Bereich.

Die Angabe der Primären Gruppe in Active Directory-Benutzer und -Computer

Warum gibt es die Primary Group, und was ist das Problem damit?

Windows selbst benötigt die Primary Group nicht, ebenso wenig Active Directory. Bei jedem Benutzerobjekt ist sie allerdings eingetragen, normalerweise die Gruppe “Domänen-Benutzer”. Tatsächlich dient dieser Eintrag nur der POSIX-Kompatibilität, also für eine mögliche Interaktion mit Unix-Systemen (auch für Macintosh konnte so etwas nötig sein, aber da ging es um die Zeit vor OS X). POSIX ist ein Betriebssystemstandard, der für Unix-Systeme relevant ist.

In der frühen Entwurfsphase von Windows NT (Anfang der Neunzigerjahre!) bestand ein Ziel darin, eine gewisse Kompatibilität zu POSIX herzustellen. Dieser Standard sieht vor, dass jeder Benutzer (genau) einer Gruppe angehört. Dies bildete Windows NT als “Primary Group” ab. Benötigt man diese Unix-Interoperabilität nicht (und man benötigt sie eigentlich nie, auch nicht, wenn man Unix oder Linux im eigenen Netzwerk betreibt), dann ist diese Gruppenmitgliedschaft eigentlich obsolet.

Thorsten Butz wies mich auf ein weiteres Einsatzgebiet der Primary Group hin: Wenn man dynamisch Berechtigungen für eine Gruppe vergeben möchte, der der Ersteller einer Datei angehört (Creator-Owner-Group), dann ist dafür die Primary Group ausschlaggebend. Auch dies ist allerdings ein hochgradig exotischer Fall, der mir selbst in 16 Jahren Active Directory noch nicht untergekommen ist. Es bleibt also dabei: In den allermeisten Umgebungen braucht man die Primary Group – nie.

Und was ist nun das Problem?

Die Primary Group wird anders gespeichert als normale Gruppenmitgliedschaften. Nimmt man einen Benutzer in eine AD-Gruppe auf, so wird die Mitgliedschaft bei der Gruppe gespeichert (in deren Feld “member”). Das Feld “memberOf” (in der grafischen Oberfläche eben: “Mitglied von”) ist ein so genannter “Backlink”, der eigentlich gar nicht gespeichert, sondern aus den Gruppenmitgliedschaften errechnet wird. Er dient im Wesentlichen der Bequemlichkeit, weil man so schneller nachsehen kann, wo ein User Mitglied ist.

Das Feld “member” einer Gruppe gibt deren Mitglieder an

Die Primary Group hingegen wird direkt im User-Objekt gespeichert, und zwar im Feld “primaryGroupID”. Dort steht aber nicht etwa der Name der betreffenden Gruppe, sondern nur ihr RID (Relative Identifier). Das ist der letzte Abschnitt der SID (Security Identifier), also ohne den Domänenteil davor.

Das Feld “primaryGroupID” bei einem Userobjekt enthält den RID der betreffenden Gruppe. Der Wert 513 steht die die “Domänen-Benutzer”

Ganz wichtig: Das bedeutet, dass die Zuordnung einer Primary Group nicht im “member”-Feld der betreffenden Gruppe gespeichert wird! Die Gruppe selbst “weiß” also gar nicht, dass diese Mitglieder auch dazugehören!

Das kann man auch zeigen: Fragt man das Feld “member” einer Gruppe ab, dann tauchen die User nicht auf, die diese Gruppe als Primary Group eingetragen haben. In den meisten Umgebungen sieht man dies sehr schön an der Gruppe “Domänen-Benutzer”, die nämlich scheinbar (fast) leer ist.

Nun kommt das Hinterlistige: Die AD-Verwaltungstools kennen diesen Mechanismus und rechnen die Primary-Group-Mitglieder stillschweigend hinzu. Schaut man also im grafischen Verwaltungstool nach, sieht man eben doch “alle” Mitglieder. (Dasselbe gilt für viele andere mitgelieferte Tools, z.B. net group oder die ds*-Tools.)

Das Feld “member” der “Domänen-Benutzer” ist meistens leer. Die grafische Verwaltung schummelt hier und rechnet die Primary-Group-Mitglieder hinzu!

Ja, und das Problem?

Ein wirkliches Problem entsteht hieraus, wenn Administratoren die Primäre Gruppe eines Benutzers ändern. Oft tun sie das aufgrund einer falschen Annahme: Wenn etwa jemand im Vertrieb arbeitet, setzen sie die Vertriebsgruppe als Primäre Gruppe. Dadurch aber verschwindet dieser Benutzer in Wirklichkeit aus der Vertriebsgruppe! Der Administrator sieht das aber nicht, weil die Verwaltungstools das Mitglied ja doch anzeigen. Um die Verwirrung komplett zu machen, wird in diesem Fall das betreffende Userobjekt stillschweigend im Hintergrund als “normales” Mitglied in die Gruppe “Domänen-Benutzer” aufgenommen.

Magda Nalyse hat die Gruppe “GG-Vertrieb” als Primäre Gruppe. In deren Mitgliedsliste (im Bild links) taucht sie daher nicht mehr auf …

Soll nun beispielsweise eine Gruppe geleert werden, dann entfernt man dadurch nur die Mitglieder, die über das “member”-Attribut dort Mitglied sind. Die Primary-Group-Mitglieder erreicht man so nicht.

Oder andersrum: Zu Reporting-, Dokumentations- oder Analysezwecken liest man die Mitglieder einer Gruppe aus. Die Liste ist dann aber möglicherweise nicht vollständig, weil eben die Primary-Group-Mitglieder fehlen.

Und noch ein Nebeneffekt: Systeme wie Exchange betrachten ebenfalls nur die “echten” Mitglieder einer Gruppe, nicht die Primary-Group-Mitglieder. Setzt man also bei einem Benutzer eine Gruppe als Primäre Gruppe, die auch als Exchange-Verteiler dient, dann kann man über das Globale Adressbuch von Exchange nicht feststellen, dass dieser Benutzer zu dem Verteiler gehört – er taucht dort nicht auf. Die Mitgliedschaft funktioniert aber trotzdem, der Benutzer erhält also die Mails, die man an die Gruppe sendet.

Oha. Und was heißt das?

Windows und Active Directory brauchen die Primäre Gruppe nicht, und sie benutzen sie (eigentlich) auch nicht. Daher sollte man die Primäre Gruppe im Normalfall niemals ändern. Anders gesagt: Alle Benutzerkonten der Domäne sollten als Primäre Gruppe die “Domänen-Benutzer” gesetzt haben. Ausnahmen davon gibt es so gut wie nie.

Um nachzuprüfen, welche Benutzerkonten eine Primäre Gruppe haben, die nicht “Domänen-Benutzer” ist, sucht man im Feld primaryGroupID nach Werten ungleich 513 (denn 513 steht eben für “Domänen-Benutzer”).

Mit Active Directory-Benutzer und Computer kann man dies über eine Benutzerdefinierte Suche mit diesem LDAP-Filter tun:

"(&(objectClass=user)(objectCategory=person)(!primaryGroupID=513))"

In unserem SQL-basierten AD-Abfragetool Carmen könnte eine solche Abfrage so lauten:

SELECT name,member FROM 'LDAP://DC=domain,DC=tld' WHERE objectClass='user' and objectCategory='person' and primaryGroupID <> '513'

Das hervorragende Abfragetool AdFind von Joe Richards erledigt die Aufgabe so:

adfind -f "(&(objectClass=user)(objectCategory=person)(!(primaryGroupID=513)))" dn sAMAccountName primaryGroupID memberOf

Auch hier eine Ergänzung: Thomas Franke hat ein PowerShell-Skript veröffentlicht, das diese Aufgabe sehr elegant löst.

[Active Directory Primary Group auslesen]
http://www.powercli.de/active-directory-primary-group-auslesen/