Windows Gruppen und Berechtigungen

Beachten Sie dazu auch die Seite ADSync und Gruppenmitgliedschaft

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 können sollten. Dabei geht es im wesentlichen um:

  • Sichtbarkeit der Gruppen
    Es gibt Gruppen, die nur innerhalb einer Domäne genutzt werden können, solche, die
  • Verschachtelung
    Es ist besonders wichtig zu wissen, welche Gruppen welche Personen und anderen Gruppen als Mitglieder haben können. Nicht alle Gruppen können frei genutzt werden
  • Verwendung für Exchange
    Wird eine Gruppe in Exchange genutzt, so muss diese Exchange aktiviert werden und sollte im globalen Katalog für alle Exchange Server einfach aufzulösen sein (-> universelle Gruppen).
  • Bedeutung der SID
    Wird der Verteiler zur Vergabe von Berechtigungen genutzt, so müssen diese Gruppen zusätzlich eine SID habe. (-> Sicherheitsgruppen)

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:

  • Rechte auf Freigaben, Dateien und Verzeichnisse
    Der klassische Einsatz von Gruppen
  • Rechte auf Drucker
    Besonders teure Farbdrucker sollen nicht für "Jeder" zugänglich sein
  • Rechte für die Nutzung von Internet und RAS
    Speziell mit dem ISA-Server und RRAS können über Gruppen elegant die Zugriffe gesteuert werden.
  • Einschränken von Gruppenrichtlinien
    Wenn bestimmte GPOs nicht über die OU-Struktur oder WMI (ab 2003) gefiltert werden können, können Sie mit Gruppen eine Filterung erreichen
  • Administrative Berechtigungen
    Wenn jemand z.B.: auf einer OU die Berechtigungen haben soll, Computer anzulegen oder die Kennworte von Benutzern zurücksetzen muss, bieten sich Gruppen an. Dies gilt auch für den Zugriff auf Client mittels Fernsteuerung, die Vergabe lokaler Administratorenrechte und anderes
  • Abteilungsgruppen
    Die Zusammenfassung der Mitarbeiter einer Abteilung in einer Gruppe erlaubt dann die einfache Vergabe über Berechtigungsgruppen.
  • Projektgruppen
    Fach- und Abteilungsübergreifende Gruppen werden häufig temporär angelegt
  • Exchange Verteiler
    Zuletzt sind Gruppen natürlich auch für Exchange sehr wichtig

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 dokumentieren !

Ehe Sie wie wild anfangen, Verteiler und Sicherheitsgruppen anzulegen, sollten Sie sich Gedanken über die Dokumentation machen. Denn in ein paar Jahren wissen nicht nicht mehr, wozu welche Gruppe noch mal angelegt wurde. Viel schlimmer ist noch, dass eine Gruppe an verschiedenen Stellen berechtigt werden kann. Das ist nicht nur eine ACL auf einem Share oder einem NTFS-Objekt, sondern das können ja auch Exchange Stellvertreter, Verteiler oder Rechte auf öffentliche Ordner sein. Auch Sharepoint, SQL, ISA-Server, IIS und letztlich auch im Active Directory werden mit Vorliebe "Gruppen" für die Vergabe von Berechtigungen eingesetzt.

Es gibt aber keinen einfachen Weg, um rückwärts zu ermitteln, welche Gruppe wo eingesetzt wird. !

Daher sollten Sie pro Gruppe eine Mindestdokumentation anlegen. Das kann an der Gruppe selbst passieren (Bemerkungsfeld, Manager) oder eine eigene Dokumentation sein. Wichtig ist nur, dass es passiert.

Was Wozu

Gruppenname

Sie müssen ja wissen, zu welcher Gruppe die folgenden Informationen gehören. Es bietet sich an die Domain und den SAM-Account Name zu nutzen. Der DN kann sich ja doch ändern aber die Verwendung einer GUID ist nicht praktikabel. Wer Gruppen umbenennt, muss dies natürlich dann auch in der Dokumentation anpassen.

SID

Nicht ganz einfach aber ratsam ist die Dokumentation der SID. Spätestens wenn die Gruppe irgendwann wieder gelöscht wird, und sie vergessene ACLs finden, hilft ihnen dann die Dokumentation die frühere Gruppe zu identifizieren.

Angelegt durch

Speziell für Rückfragen sollte dokumentiert sein, welcher Admin die Gruppe angelegt hat. Wer ein passendes Adminkonzept hat, kann aber auch dies notfalls wieder aus dem AD oder Eventlog extrahieren.

Angelegt am

Diese Feld kann man aber auch einfach aus dem Active Directory (whenCreated) extrahieren

Verantwortliche Person

Eigentlich dürfte es nie ein Objekt geben, welches niemandem "gehört". Dann gehört es nämlich gelöscht. Das AD kennt dazu extra das Feld "Manager". Füllen Sie es, da diese Person letztlich entscheiden muss, was mit der Gruppe passiert (z.B. Mitglieder oder letztlich auch Löschen der Gruppe). Es gibt sogar Tools, die an den Manager bei Änderungen einfach eine Meldung erstatten

Einsatzzweck

Sie sollten sich schon ein paar Minuten nehmen, um den geplanten Verwendungszweck einer Gruppen zu beschreiben. Dazu gehören insbesondere Abhängigkeiten zu anderen Objekten und die Dokumentation, wo diese Gruppe verwendet wird, z.B.: wenn Sie in einem Share zur Vergabe von Berechtigungen auftaucht.

Mitglieder

Statische Gruppen können so auch dokumentiert werden. Wer es moderner mag, kann diese Information natürlich mit dem AD abgleichen oder prüfen und bei Unstimmigkeiten den Manager benachrichtigen.

Änderungen

Änderungen an der Gruppe sollten hier ebenfalls dokumentiert werden. Es gibt Produkte, die Änderungen z.B. im AD erkennen und ein Änderungstagebuch mitschreiben. Eine Änderung könnte aber auch auf Servern erfolgen (z.B. Berechtigungen), die so nicht erkannt würde.

Auch wenn es erst mal nach mehr Arbeit aussieht, so hilft es später doch, wenn Sie mal "aufräumen" wollen, z.B. wenn es zu viele Gruppen gibt oder diese unübersichtlich verschachtelt sind. Es passiert ja auch immer mal wieder, dass eine Anwendung entfällt und dann sollten auch Sicherheitsaspekten auch die ACLs und die Gruppe sauber entfernt werden. Niemand mag kryptische SIDs in ACLs, die nicht mehr zugeordnet werden können.

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.

  • LG = Domänenlokale Gruppe#
    Nur innerhalb der Domäne verwendbar
  • GG = Globale Gruppe
    Auch über Domänengrenzen hinaus verwendbar, aber die Liste der Mitglieder sind nicht im globalen Katalog verfügbar
  • UG = universelle Gruppe
    Einzige Gruppe, in der quasi jeder und alles aus dem gleichen Forest Mitglied sein kann
  • W3K
    Die Gruppen und Benutzer sind in einer Windows 2003 Domäne angelegt
  • NT4
    Die Gruppen und Benutzer sind in einer vertrauten Domäne (z.B. Windows NT4 Domäne oder anderer Forest) angelegt.

Eine gute Auflistung gibt es auch bei Microsoft:

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.

  • Globale Gruppen können nur Objekte aus der gleichen Domäne beinhalten.
  • Globale Gruppen können in beliebige lokale Gruppen aufgenommen werden.

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:

  • 120 Mitgliedschaften
    Ein Puffer für die Übergabe von Tokens ist natürlich nicht endlos und wenn ein Benutzer in mehr als 120 Sicherheitsgruppen enthalten ist, kann es Probleme bei der Anmeldung geben.
    Siehe 327825 New Resolution für Problems That Occur When Users Belong to Many Groups
  • 200 Mitgliedschaften
    Im KB-Artikel 818526 wird ein Hotfix für Server ActiveSync beschrieben, um Probleme mit mehr als 200 Gruppenmitgliedschaften zu umgehen.
  • 1015 Mitgliedschaften
    Es gibt einige Prozesse, die die Mitgliedschaften für Entscheidungen verwenden, z.B. Gruppenrichtlinien. Es kann hier zu Problemen kommen, wenn ein Benutzer in mehr als 1024 Gruppen ist. Zur Sicherheit sollten Sie aber einen User nicht in mehr als 1015 Sicherheitsgruppen aufnehmen
    Siehe 328889 Users Who Are Members of More Than 1,015 Groups May Fail Logon Authentication
  • 5000 Mitgliedschaften
    Bei Windows 2000 Domain Controller ist der Buffer für die Replikation zwischen Servern begrenzt. Da bei Windows 2000 das Feld "Member" immer komplett repliziert wird, ist bei ca. 5000 Objekten eine Obergrenze erreicht. für größere Gruppen müssen Sie Gruppen in Gruppen verschachteln oder auf Windows 2003 DC's Updaten.
    Auch ein Parameterlimit unter Win2008 kann viele Programme stören, die z.B. Members oder MemberOf auslesen und dort mehr als 5000 Einträge enthalten wären.
  • Sharepoint 2013: 5000 Mitglieder
    Number of SharePoint 2013 groups a User can belong to = 5000
    Quelle: http://technet.microsoft.com/en-us/library/cc262787.aspx
  • Office 365: 50.000 Mitglieder
    Per DirSync können maximal Gruppen mit 50.000 Mitgliedern repliziert werden
    Quelle:https://azure.microsoft.com/en-us/documentation/articles/active-directory-service-limits-restrictions/
  • Primary Group
    Jeder Benutzer hat eine "primäre" Gruppe. Dies sollte eine der Standardgruppen sein. Abweichungen werden gemeldet. Details hierzu finden Sie auf Windows Gruppen und Berechtigungen. Zudem muss die primäre Gruppe bei der Ermittlung von Member und MemberOf berücksichtigt werden.

Auch umgekehrt muss man besonders bei Skripten aufpassen. Ein Domaincontroller liefert bei einer Abfrage von "Members" bei einer Gruppe nur 1000 (Win2000) oder 1500 /Win2003+) Mitglieder zurück. Wenn mehr Mitglieder enthalten sind, muss der Programmierer ein "RangeSearch" machen.

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:

  • Ideale Gruppe für die Vergabe von Rechten sind domänenlokale Gruppen und serverlokale Gruppen
    Dies gilt, solange die Server und Dienste in der lokalen Domäne aufgestellt sind. In mehreren Domänen sind entsprechend mehrere lokale Gruppen erforderlich.
  • Niemals Benutzer eintragen
    Zuständigkeiten und Funktionen ändern sich. Es ist einfacher Personen aus Funktionsgruppen zu entfernen oder wieder aufzunehmen als in allen ACL’s nach dieser Person zu fahnden und diese zu löschen. Wird ein Benutzer gelöscht, gibt es keinen automatischen Weg, diese SID aus allen ACL’s zu entfernen
  • Verwenden Sie möglichst nicht die „Systemgruppen“
    Gruppen wie „Domänen Benutzer“ oder „„Domänen Administratoren“„haben eine besondere SID, die auch bei der Migration von Gruppen (SID-History) nicht übernommen werden kann. Damit werden spätere Umstrukturierungen sehr aufwändig, da auch die Rechte dieser Gruppen nicht migriert werden können.
    Zudem sind auch Praktikanten und andere Personen immer Mitglied von „Domänen Benutzer“. Verwenden Sie für solch allgemeine Berechtigungen eine Gruppe „Mitarbeiter“ oder eine Abteilungsgruppe.
  • Keine Rechte an globale Gruppen
    Globale Gruppen können nur Objekte der gleichen Domäne enthalten, Es ist daher immer besser, die Rechte an lokale Gruppen zu binden, die andere Gruppen als Mitglieder haben. Ansonsten müssen Sie später bei der Ressource mehrere globalen Gruppen aus anderen Domänen hinzufügen und verwalten. Die erschwert die Übersichtlichkeit, welche fremde Gruppe Zugriffsrechte hat.
  • Universelle Gruppen
    Die Zusammenfassung mehrerer Personen in eine Gruppe anhand universeller Gruppen ist dann von Vorteil, wenn viele Dienste von der Verfügbarkeit im Globalen Katalog profitieren und damit die erhöhte Belastung für die Replikation rechtfertigen. Exchange erfordert zwingend universelle Gruppen als Verteiler, weil nur diese in alle Globalen Kataloge repliziert und von allen Exchange Servern damit auflösbar sind.
  • Ausnahme: Rechte auf AD-Objekte
    Die Schemapartition und die Configuration Partition des Active Directory sind nicht auf einen Server oder eine Domäne begrenzt. Daher sind Berechtigungen über lokale Gruppen nicht nutzbar, da nicht alle Domain Controller in einem Forest diese Gruppen auflösen können. Hier sind globale oder universelle Gruppen zu nutzen. Dies betrifft auch die Vergabe von Rechten innerhalb von Exchange.
  • Vorsicht mit primären Gruppen
    Jedes Objekt (Datei, OU, Benutzer etc.), welches durch einen Benutzer angelegt  wird, erhält diesen Benutzer und seine  primäre Gruppe als "Owner". Und der Besitzer eines Objekts hat immer besondere Rechte, selbst wenn die Gruppe oder der Benutzer nicht in der eigentlichen ACL auftaucht.

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.

  • Blockade der Vererbung
    Auf dem Objekt selbst kann kontrolliert werden, ob dieses Objekt die Berechtigungen des darüber liegenden Objekts übernimmt. Ist dies nicht gewünscht, kann diese Vererbung abgeschaltet werden und ab dieser Stufe müssen die Rechte frisch vergeben werden. Windows erlaubt dazu eine Kopie der bisher vererbten Rechte.
    Dies ist aber besonders bei Exchange und Dateisystemen nicht das Gleiche. Zwar hat sich im ersten Moment nichts an den Rechten geändert, aber werden später auf einer höheren Ebene neue rechte (z.B.: neue Gruppen, weitere Server etc.) hinzu gefügt, so vererben sich diese Einstellungen nicht mehr in diesen Zweig weiter.
    Von dieser Methode sollte daher nur sehr vorsichtig und dokumentiert gebrauch gemacht werden.
  • Verweigern von Rechten (DENY)
    Eine weitere Möglichkeit ist die Vergabe von expliziten „Verbotsrechten“. Die betroffenen Benutzer haben dann die verbotenen Rechte nicht mehr. Dabei gilt zu beachten, dass ein „Verbot“ immer dominierend ist. Im schlimmsten Fall können damit auch der Gruppen „Domänen Administratoren“ notwendige Rechte entzogen werden. Besonders gefährlich sind Aussagen wie „Jeder darf nicht, nur der Geschäftsführer darf“. Dies kann über Verbotsrechte nicht umgesetzt werden, da auch der Geschäftsführer in der Systemgruppe „Jeder“ ist. Sogar die Domain Controller und Systemdienste zählen hierzu.
    DENY-Rechte sind daher sehr umsichtig zu verwenden. Besser ist hier, das Recht erst überhaupt nicht zu vergeben
  • Steuerung der Vererbung
    Meist unbekannt ist die Möglichkeit schon bei der Eintragung der Berechtigungen pro ACL-Eintrag zu steuern, ob und wie weit diese Rechte vererbt werden. Damit ist es möglich, dass ein Benutzer zwar Rechte auf ein Objekt aber nicht auf die Unterobjekte erhält, ohne die globale Vererbung zu unterbrechen oder gar Rechte verbieten zu müssen.

Betrachtung der verschiedenen Ansätze

Abbildung Beschreibung

  • 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 Configuration-Partition, welche unabhängig von der Domäne existiert. Ein Beispiel:

Gegeben ist folgende einfacher Struktur:

  • Anwender: domain1.forest1.de/User1
  • Gruppe: domain1.forest1.de/USG1
    (universal Security group)
    Mitglied: domain1.forest1.de/User1
  • Gruppe: domain2.forest1.de/LG1
    (Domänen lokale Gruppe)
    Mitglied: domain2.forest1.de/User1

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:

  • Anmeldung an einem PC der Domäne domain1.forest1.de
    Anmeldedomäne des Benutzers domain1.forest1.de
    Computerdomäne: domain1.forest1.de
    Benutzername: domain1.forest1.de/User1
    Group: domain1.forest1.de/USG1
  • Anmeldung an domain2.forest1.de/PC2
    User: domain1.forest1.de/User1
    Group: domain1.forest1.de/USG1
    Alias: domain2.forest1.de/LG1

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:

  • Member
    Dieses Feld gibt es nur bei Gruppen und enthält die Mitglieder dieser Gruppe. Allerdings sind nur die Benutzer und Computer enthalten, die diese Gruppe nicht als primäryGroupID haben.
  • MemberOf
    Dieses Feld beim Benutzer enthält den DN aller globalen und universellen Gruppen, in denen der Benutzer Mitglied ist. Allerdings sind hier keine lokalen Gruppen und die primäre Gruppe enthalten
  • PrimaryGroupID
    Siehe folgendes Kapitel

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.

  • 275523 Setting primäry Group Excludes the User from the Group Membership in Active Directory
  • 321360 How to use native ADSI components to find the primäry group
  • Primarygroup
    http://www.rlmueller.net/primary_group.htm

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