Windows Gruppen und Berechtigungen

Beim Einsatz von Exchange im Unternehmen werden Sie auch mit Verteilern arbeiten wollen. Die Verteiler von Exchange sind in Wirklichkeit Gruppen im Active Directory. Die Verwendung von Gruppen unterliegt aber einigen Beschränkungen, die Sie als Administrator einer Domäne aber auch von Exchange kennen sollten. Dabei geht es im wesentlichen um:

Daher ist ein kurzer Exkurs in die Welt der Windows Gruppen erforderlich:

Wozu Gruppen ?

Der Einsatz von Gruppen ist in einem Windows Netzwerk sehr vielfältig möglich und auch angeraten. Sie sollten es auf jeden Fall vermeiden, einzelne Benutzer für die Vergabe von Berechtigungen zu verwenden, sondern möglichst immer über Gruppen arbeiten. Benutzer werden gerne auch in andere Domänen oder Abteilungen verschoben so dass sich deren Tätigkeiten ändern. Es ist dann sehr schwer, die bestehenden Berechtigungen wieder zu finden und erst recht diese einem neuen Benutzer zu geben, der die gleiche Funktion übernimmt. Daher sollten Sie immer mit Gruppen arbeiten. Gruppen werden z.B. eingesetzt für:

Denken Sie auch daran, ein Namenskonzept und OU-Konzept für die Gruppen zu erstellen, dass Sie diese später einfach wieder finden und die Funktion beschreiben.

Gerade die Systemgruppen und Objekte des Active Directory sollten Sie nicht für normale Anwender nutzen, da Windows hier die Berechtigungen immer wieder auf Defaults setzt.

Gruppen und Mitgliedschaften.

Bei der Planung von Domänen, Gruppen und Benutzern müssen Bedingungen für die Mitgliedschaften betrachtet werden. Nicht alle Gruppen können alle anderen Objekte als Mitglieder aufnehmen.

Folgende Übersicht verdeutlich die verschiedenen Möglichkeiten der Mitgliedschaft.

Windows 2003 im mixed Mode und NT4 Domäne

Folgende Mitgliedschaften sind in einer gemischten Windows 200x Domäne möglich:

Gruppe mögliche Mitglieder
  LG-W3K GG-W3K UG-W3K User W3K LG-NT4 GG-NT4 User NT4
LG-W3K Nein Ja entfällt Ja Nein Ja Ja
GG-W3K Nein Nein entfällt Ja Nein Nein Nein

UG-W3K

 entfällt entfällt entfällt entfällt entfällt entfällt entfällt
LG-NT4 Nein Ja entfällt Ja Nein Ja Ja
GG-NT4 Nein Nein entfällt Nein Nein Nein Ja

Sie können keinen universelle Gruppen nutzen und auch die Rekursion von Gruppen ist nicht möglich.

Windows 2003 im native Mode

Die Unterschiede im Native Mode betreffen überwiegend die universelle Gruppen aber auch die Rekursion von lokalen und globalen Gruppen erweitert die Möglichkeiten und sind farblich verdeutlicht.

Gruppe mögliche Mitglieder
  LG-W3K GG-W3K UG-W3K User W3K LG-NT4 GG-NT4 User NT4
LG-W3K Ja Ja Ja Ja Nein Ja Ja
GG-W3K Nein Ja Nein Ja Nein Nein Nein
UG-W3K Nein Ja Ja Ja Nein Nein Nein
LG-NT4 Nein Ja Ja Ja Nein Ja Ja
GG-NT4 Nein Nein Nein Nein Nein Nein Ja

Die grafische Übersicht der möglichen Mitgliedschaften einer Windows 200x Native Mode Domäne:

Generell gültige Aussagen:

Wenn Sie die verschiedenen Gruppen und Mitgliedschaften etwas verwirren, hier zwei immer gültige Aussagen, die auch fast immer ausreichen.

Es gibt ein unterschied zwischen „Domänenlokale“ Gruppen und lokalen Gruppen. Während bei Windows NT4 die Domänenlokalen Gruppen nur auf den Domain Controllern verfügbar waren, sind seit Windows 2000 die domänenlokalen Gruppen in der lokalen Domäne auch von Mitgliedsservern nutzbar.

Lokale Gruppen auf Mitgliedsservern sind jedoch weiterhin immer lokal auf diesen PC beschränkt. Mitglieder können jedoch wie bei der domänenlokalen Gruppe auch aus anderen Domänen sein.

Mitgliedschaft in vielen Gruppen

Ein Benutzer kann in sehr vielen Gruppen Mitglied sein. Das sind nicht immer nur direkte Mitgliedschaften, sondern auch Mitgliedschaften über Gruppen die ihrerseits wieder in anderen Gruppen Mitglied sind. Es gibt hier einig Grenzen zu bedenken:

Weitere Hinweise finden Sie auch auf

Gruppen und Berechtigungen

Zwar wissen Sie nun, dass Gruppen dazu da sind, Benutzer zusammen zu fassen und über Gruppen verschiedene Rechte an Objekte zu vergeben, aber wie sieht das "praktisch" aus ?

Rechte auf Verzeichnisse, Dateien und andere Objekte werden auf Basis von Access Control Lists (ACLs) vergeben. Teil einer ACL können sowohl Benutzer als auch Gruppen sein. Folgende Mitgliedschaften haben Sich bei der effektiven Verwaltung bewährt:

Best Practice für Berechtigungen:

Vererbung und Blockade

Ein weiterer Aspekt bei der Betrachtung der Vergabe administrativer Berechtigungen ist die Möglichkeit der Vererbung und Steuerung der Vererbung.

Seit Windows 2000 wurde von Microsoft die Vererbung beim Dateisystem eingeführt. Berechtigungen auf Dateien und Ordner werden standardmäßig auch auf alle Unterordner vererbt.

Durch diese Konstruktion haben Personen auf tiefer liegende Objekte meist die gleichen oder über explizit vergeben sogar mehr Rechte. Der Fall, dass in einer Unterstruktur jemand weniger Berechtigungen als auf der darüber liegenden Struktur hat, kann durch folgende drei Verfahren ermöglicht werden.

Betrachtung der verschiedenen Ansätze

  • Funktionsgruppen werden in die ACLs oder lokale Gruppen eingetragen.
  • Benutzer werden je nach Berechtigungen in die erforderlichen Gruppen eingetragen.

Für mehrfache Berechtigungen müssen Benutzer in mehrere Gruppen eingetragen werden. Dies bedeutet, dass bei einem neuen Anwender oder Änderungen mehrere Mitgliedschaften gepflegt werden müssen. So kann ein Exchange Administrator nur dann Exchange administrieren, wenn er sowohl Administrator auf dem Server, in Teilen der Exchange Organisation und vielleicht noch der OU mit den Anwendern ist.
  • Funktionsgruppen werden in die ACLs oder lokale Gruppen eingetragen.
  • Benutzer werden je nach Berechtigungen in die erforderlichen Gruppen eingetragen
  • Für mehrfache Berechtigungen werden Gruppen kaskadiert, d.h. ein eine Gruppen beschreibt eine Berechtigung komplett.

Sofern die Funktionsgruppe 2 die gleichen Recht benötigt, wie die Funktionsgruppe 1 und zusätzlich weitere Berechtigungen erhält, kann die Kaskadierung solcher Gruppen hilfreich sein. Allerdings hat Die Funktionsgruppe 2 dann immer auch die Rechte von Funktionsgruppe

  • Funktionsgruppen werden in die ACLs oder lokale Gruppen eingetragen.
  • Benutzer werden je nach Berechtigungen in die erforderlichen Gruppen eingetragen
  • Für mehrfache Berechtigungen werden Gruppen in die entsprechenden ACLs eingetragen

Damit beschreibt eine Gruppe sehr genau die Funktion, aber die ACLs der entsprechenden Objekte enthalten viel mehr Gruppen. Änderungen sind etwas aufwändiger.

So könnte es aussehen?

Sie möchten mehrere administrative Funktionen zusammenfassen, dann benötigen Sie entsprechende Gruppen mit den Mitgliedern. Diesen Gruppen geben Sie dann die Rechte auf die entsprechenden Objekte. Das kann "indirekt" über lokale oder domänenlokale Gruppen erfolgen (z.B.: Rechte auf Server, Freigaben, Datei und Ordner) oder direkt unter Einsatz der globalen Gruppen (z.B. auf OU's , Exchange Berechtigungen etc.)

Soweit ein kleiner Exkurs, der natürlich kein vollständiges Berechtigungsmodell oder Planung ersetzen kann. Gruppen sind nicht nur für Exchange, sondern auch für Funktionen, Abteilungen, Verteiler, Zugriff auf Dienste wie Internet, Drucker, RAS etc. einsetzbar. Daher sollten Sie sich vorab die Zeit für eine Planung nehmen.

Gruppen in Multi Domain Umgebungen

Gerade beim Einsatz in mehreren Domänen ist die Wahl der richtigen Gruppe für die Funktion wichtig. Wenn Sie z.B. Berechtigungen in der Exchange Organisation geben wollen, können Sie dazu lokale, global oder universelle Gruppen verwenden. Aber nur die universelle Gruppe ist wirklich geeignet, da nur diese auch von allen DCs aller Domänen aufgelöst werden kann. Denn die Active Directory mit den Exchange Konfigurationsdaten ist die Config-Partiton, welche unabhängig von der Domäne existiert. Ein Beispiel:

Gegeben ist folgende einfacher Struktur:

Wenn Sie nun als Gegenprobe beim Benutzer einmal kurz die Mitgliedschaften auflisten, dann werden Sie erkennen, dass die Gruppe "domain2.forest1.de/LG1" nicht mit aufgeführt wird, obwohl der Anwender ja dort eingetragen ist. Das ist normal.

Was passiert nun bei der Anmeldung ?. Hier gibt es zwei Fälle zu unterscheiden:

Die Anzeige der ermittelten Gruppenrichtlinien können Sie mit dem Programm "WHOAMI /all".

Bei der Anmeldung eines Anwenders an einer Workstation passiert genau genommen folgendes:

  1. Autorisierung des Benutzers
  2. Lesen der Mitgliedschaften vom DC der Userdomain
  3. Lesen der Mitgliedschaften in Gruppen aus der Computer Domäne (Alias)
  4. Lesen der Mitgliedschaften in lokalen Gruppen auf dem System

Ergebnis: Rechte durch die Mitgliedschaft in domainlokalen Gruppen einer anderen Domäne greifen nur, wenn die Anmeldung an einem System dieser Domäne erfolgt. Daher sind domainlokale Gruppen nur bedingt zur Administrator organisationsweiter Einstellungen (z.B. Exchange) geeignet. Ein Beispiel:

  1. Ihr Benutzerkonto ist in Domäne1
  2. Die domainlokale Sicherheitsgruppe ist in Domäne 2
  3. Ihr Benutzer ist Mitglied dieser Gruppe
  4. Die Gruppe wurde in Exchange zur Berechtigung verwendet

Nun gibt es folgende Matrix

  Zugriff auf DC/GC in Domäne 1 Zugriff auf DC/GC in Domäne 2
Anmeldung auf PC in Domäne 1

Verwaltung nicht möglich, da die LDAP-Anfrage nur die SID-Credentials aus Domäne 1 enthält.

Verwaltung vermutlich nicht möglich, da die LDAP-Anfrage nur die SID-Credentials aus Domäne 1 enthält
Anmeldung auf PC in Domäne 2

Verwaltung fraglich, da die LDAP-Anfrage zwar SID-Credentials der Gruppe aus Domäne2 enthält, aber der DC der Domäne 1 kann diese domänenlokale Gruppe der Domäne 2 natürlich nicht verifizieren (Außer bei Nutzung von Kerberos)

Verwaltung problemlos möglich. Der Benutzer hat alle benötigten SIDs erhalten

Die beiden fraglichen Bereiche sind sogar abhängig von der Umgebung, da einige Anmeldungen über Kerberos in einem Fall schon funktionieren sollten, aber ich denke die Tabelle zeigt sehr gut, dass Sie für bestimmte Funktionen auch die richtige Gruppe auswählen müssen, um das gewünschte Ziel auch zuverlässig zu erreichen.

Übrigens: Das Attribut "MemberOf" ist nicht Bestandteil des Globalen Katalogs. Daher bedeutet die Anmeldung an einem entfernten Standort mit einer andere Domäne, dass der PC einen DC der Benutzerdomäne suchen muss.

Member, MemberOf

Werfen wir noch einen Blick hinter die Kulissen des Active Directory und wie die Mitgliedschaften gespeichert werden. Hier kommen drei Felder zum Tagen, von denen sich zwei Felder recht schnell erschließen:

Aufgrund der Tatsache, dass lokale Gruppen nicht in der MemberOf-Liste des Benutzers auftauchen, sollten Sie Benutzer nur in globalen Gruppen aufnehmen. Dies lässt sich leichter dokumentieren, da sie ansonsten auf jedem Server die lokalen Gruppen auslesen müssten.

Auch universelle Gruppen tauchen nicht immer in der Liste auf. Siehe
833883 You cannot view a user's universal group membership in Windows Server 2003 Active Directory Users and Computers when universal groups do not reside in the local domain

Die Pflege dieser Felder erfolgt in den meisten Fällen über die Gruppe, in die ein anderes Objekt aufgenommen wird. Es kann nämlich sein, dass Sie zwar die Gruppe administrieren dürfen, aber nicht das Objekt, welches Sie in die Gruppe aufnehmen. In dem Fall können Sie das Feld "MemberOf" beim dem anderen Objekt gar nicht ändern. Wenn Sie z.B.: mittels ADSIEDIT versuche, dass Feld "MemberOf" zu ändern, dann bekommt Sie folgende lapidare Fehlermeldung:

Sie können daher gar nicht das Feld "MemberOf" bei einem Benutzer pflegen. Diese Aufgabe übernimmt der Infrastrukturmaster für Sie. Dass es bei dieser "Lösung" zweiter Felder, die gegenseitig auf sich verweisen, auch mal zu Inkonsistenzen kommen kann, liegt nahe.

So gibt es Fälle, bei denen der Infrastrukturmaster (z.B.: wenn er auch einem GC läuft) nicht immer ordentlich arbeitet. Auch ein Restore von einem Objekt restauriert sein Feld "MemberOf" aber natürlich nicht das Feld "Member" bei der Gruppe. dazu gibt es von Microsoft sogar ein eigenes Programm:

The Groupadd.exe command-line utility reads the memberOf attribute on a collection of users in an OU and builds an .ldf file that adds each restored user account to the security groups in each domain in the forest.
Quelle: 840001 How to restore deleted user accounts and their group memberships in Active Directory

Diese Problematik decke ich auch mit meinem Tool CheckGRP ab, welches eben diese Übereinstimmungen prüft und Unstimmigkeiten meldet.

Die MMC für Benutzer und Computer hat bis Windows 2003 SP1 einen Fehler, dass nicht alle Gruppenmitgliedschaften korrekt angezeigt werden !. So werden bei einem Benutzer keine universelle Gruppen aus anderen Domänen angezeigt, obwohl diese im Feld "MemberOf" aufgeführt werden. Es gibt einen Hotfix.

PrimaryGroupID

Neben den Feldern "Member" und "MemberOf" hat jeder Benutzer noch eine "primäre Gruppe". Sie wird für POSIX und UNIX verwenden und sollte nicht geändert werden. Diese Feld hat einen numerischen Wert und enthält meist folgende Gruppen:

512 = Domain Administratoren
513 = Domain User bei Benutzern
514 = Domain Guest
515 = Domain Computer für Computer
516 = Domain Controllers

Der Hintergrund dieser Funktion ist aber ein anderer: Windows 2000 konnte maximal 5000 "Member" in einer Gruppe verwalten. Damit wäre in einem Active Directory mit mehr Benutzern aber schon die Standardgruppe "Domänen Benutzer" überfordert. Daher hat Microsoft sich so beholfen, dass die primäre Gruppe eben nicht mehr in dem Feld "member" erscheinen muss.

Umgekehrt heißt das für jede Drittsoftware aber, dass Sie zum Auflisten der Gruppenmitglieder einer Gruppe nicht nur nach dem Feld "Member" schauen darf, sondern zusätzlich auch nach der Gruppe im Feld "PrimaryGroup" aller Benutzer schauen muss. Das machen leider nicht alle Anwendungen.

Wenn man das Feld "MemberOf" bei einem Benutzer per ADSIEDIT und über die MMC für Benutzer und Computer anschaut, erkennt man schnell die Unterschiede. Die MMC zeigt auch die primären Gruppen mit an

Weitergehende Informationen finden Sie auch in folgenden KB-Artikeln.

Aufgrund der Sonderstellung der "PrimaryGroupID" sollten Sie diese nicht ändern und die Gruppen nicht für Berechtigungen verwenden. Besonders Programme und Script, die einfach nur das Feld "MemberOf" abfragen, können falsch funktionieren.

So dürfte auch WINBIND und SAMBA damit ein Problem haben, da ich per TCPDUMP sehen konnte, dass WINBIND per LDAP zuerst alle Gruppen aufzählt:

BaseDN: dc=msxfaq,dc=local, SearchScope: WholeSubtree, SearchAlias: neverDerefAliases
Filter: (&(objectCategory=group)(&(BIT_AND: (groupType)&-2147483648)(!(BIT_AND: groupType)&1))))
Attributes: ( userPrincipalName )( sAMAccountName )( name )( objectSid )

Und dann für jede gefundene Gruppe die Mitglieder aufzählt:

BaseDN: dc=msxfaq,dc=local, SearchScope: WholeSubtree, SearchAlias: neverDerefAliases
Filter: (objectSid= xxxxxxxxxxxx)
Attributes: ( member )( usnChanged )

Ich könnte mir also vorstellen dass SAMBA und WINBIND gar keine Rücksicht auf die Besonderheiten der "primaryGroup" nehmen. und immer davon ausgehen, dass die Benutzer Mitglied von "Domain Benutzer" sind. Vielleicht kann dies ja mal jemand prüfen, indem auf einen Sambashare einer Gruppe rechte gibt, und eine Benutzer eben diese Gruppe als "Primäre Gruppe" hat. Kann er noch zugreifen`?. Aus Zeitgründen habe ich das noch nicht nachgestellt.

Weitere Links

Keywords: Gruppen Member MemberOf PrimaryGroupID CheckGrp