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

  • 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)

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

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.

  • DL = Domänenlokale Gruppe
    Nur innerhalb der Domäne verwendbar

  • G = Globale Gruppe
    Auch über Domänengrenzen hinaus verwendbar, aber die Liste der Mitglieder sind nicht im globalen Katalog verfügbar

  • U = Universelle Gruppe
    Einzige Gruppe

  • 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.

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
  DL-W3K G-W3K U-W3K User W3K DL-NT4 G-NT4 User NT4
DL-W3K Nein Ja   Ja Nein Ja Ja
G-W3K Nein Nein   Ja Nein Nein Nein
U-W3K              
DL-NT4 Nein Ja   Ja Nein Ja Ja
G-NT4 Nein Nein   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 und NT4 Domäne

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
  DL-W3K G-W3K U-W3K User W3K DL-NT4 G-NT4 User NT4
DL-W3K Ja Ja Ja Ja Nein Ja Ja
G-W3K Nein Ja Nein Ja Nein Nein Nein
U-W3K Nein Ja Ja Ja Nein Nein Nein
DL-NT4 Nein Ja Ja Ja Nein Ja Ja
G-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 Mitgliedservern nutzbar.

Lokale Gruppen auf Mitgliedservern 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.

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 Resource 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.

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

  • 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

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:

  • Anwender: domain1.forest1.de/user1
  • Gruppe: domain1.forest1.de/USG1
    (universal Security group)
    Mitglied: domain1.forest1.de/user1
  • Gruppe: domain2.forest1.de/DL1
    (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/DL1" 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/DL1

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.

Weitere Links