Optimale Gruppenverschachtelung

Best Practice

Die Verwendung des seit Windows NT bekannten „A G DL P“-Konzepts ist für die einfache Verwaltung und Verständlichkeit des Gruppenkonzepts absolut unumgänglich!

Die korrekte Verwendung von Gruppen in einem Windows-System ist eigentlich eine einfache Sache – dennoch sehe ich in der Praxis meistens Umgebungen, bei welchen ohne Konzept gearbeitet wird. Ein sauberes Gruppenkonzept kann jedoch zur direkten Lesbarkeit einer Active Directory-Umgebung und Berechtigungsvergabe beitragen, ohne dass diese im Anschluss grossartig in Word & Co. dokumentiert werden müsste. In Windows-Kursen wird das „A G DL P“-Konzept geschult, was auch richtig ist. Das Problem bei vielen Kursen ist jedoch die Tatsache, dass als Grund nur der technische Aspekt angegeben wird. Dieser technische Aspekt beinhaltet v.a. die Tatsache, dass es anderweitig nicht möglich ist, Berechtigungen über Domänengrenzen hinweg zu vergeben. Dies ist zwar korrekt – aber einmal Hand aufs Herz: In wie vielen Umgebungen, welche Sie betreuen finden Sie wirklich mehr als eine einzelne Domäne vor?

Von Flugzeugen, Flughäfen und Passagieren

Beim Einsatz von Gruppen geht es grundsätzlich darum, mehreren Benutzern, auf einfache und strukturierte Weise, dieselben Berechtigungen zuweisen zu können. Dies muss auch oft über Domänengrenzen hinweg erreicht werden, falls eine Gesamtstruktur aus mehreren Domänen besteht. Schliesslich geht es darum, einen Benutzer (Passagier) von Land zu Land (Domäne zu Domäne) transportieren zu können. Dazu verwenden wir Gruppen (Flugzeuge), welche wiederum auf anderen Gruppen (Flughäfen) landen können müssen.

Bevor wir jedoch unser Diplom als Reisefachmann abschliessen, sollten wir uns erst einmal damit beschäftigen, welche Gruppen überhaupt in andere Gruppe zu verschachteln sind:

In der obigen Grafik ist ersichtlich, welche Gruppen sich in andere verschachteln lassen. Dabei habe ich verschiedene Symbole verwendet. Dazu habe ich nicht einfach nur die „binäre Variante“ mit „Ja / Nein“ verwendet, sondern wollte auch versuchen, perfekte, sinnvolle und nicht sinnvolle Verschachtelungen aufzuzeigen. Diese Unterscheidung habe ich mit dem Haken (für: funktioniert) und der entsprechenden Ziffer hervorgehoben. Das Kreuz symbolisiert, dass eine solche Verschachtelung technisch gar nicht möglich ist.

Wenn wir in der ersten Spalte, die erste Zeile anschauen, dann wird hier angegeben, dass es zwar möglich ist, einen Account (ein Benutzerkonto) in eine Domänenlokale Gruppe zu verschachteln. Dies entspricht jedoch nicht dem Konzept „A G DL P“ – es ergibt sich jedoch auch kein technischer Nachteil daraus. Deshalb ist das Fazit dieses Vorgehens: „Ja: man kann“. Wenn wir in der ersten Spalte, die zweite Zeile betrachten, dann stellen wir fest, dass ein Account (ein Benutzerkonto) gemäss Konzept in eine globale Gruppe verschachtelt werden sollte. Deshalb die Markierung: „Ja: gemäss Konzept“.

Wenn wir in der ersten Spalte, die dritte Zeile genauer unter die Lupe nehmen, dann wird man mit dem Fazit: „Ja: man kann, sollte aber nicht“ abgemahnt. Weshalb ist dies so? Die Erklärung dafür lautet wie folgt: Die universelle Gruppe ist in der ganzen Gesamtstruktur ersichtlich und wird deshalb nicht in einer Domänenpartition einer einzelnen Domäne, sondern im globalen Katalog gespeichert. Der globale Katalog wird wiederum auf alle Domänencontroller einer Gesamtstruktur repliziert, welche dafür eingerichtet sind, eine Kopie des globalen Katalogs zu erhalten.

Tipp

Welcher Domänencontroller eine Kopie des globalen Katalogs beinhaltet, wird über das Dienstprogramm „Active Directory Standorte und Dienste“ in den Eigenschaften der „NTDS Settings“ vorgenommen. Unter Windows Server 2008 lassen sich diese Eigenschaften auch über das Dienstprogramm „Active Directory Benutzer und Computer“ erreichen, indem die Eigenschaften des DC-Computerobjekts geöffnet werden.

Somit kann es in einer wirklich grossen Gesamtstruktur vorkommen, dass sehr viele Domänencontroller eine Kopie dieser Gruppe lokal gespeichert haben. Dies ist jedoch lediglich einmal die Erklärung zum Speicherort von universellen Gruppen – fehlt noch das Argument gegen das Vorgehen, Benutzerkonten direkt in diesen Gruppenbereich zu verschachteln. Das Problem dabei ist die Tatsache, dass jede Mitgliedschaft eines Objekts in einer Gruppe, in dessen Attribut „Members“ abgelegt werden und satte 32 Bytes benötigt. Wenn nun 1‘000 Benutzer Mitglied einer universellen Gruppe sind, werden demnach 32‘000 Bytes dafür benötigt. Dies steht im Gegensatz dazu, diese 1‘000 Benutzerkonten zuerst in einer globalen Gruppe zusammenzufassen und diese im Anschluss als Mitglied der universellen Gruppe zu definieren. Auf diese Weise würden nur 32 Byte im Attribut „Members“ der universellen Gruppe benötigt. Da diese universelle Gruppe wie schon vorher beschrieben auf jegliche Domänencontroller der Gesamtstruktur, welche eine Kopie des globalen Katalogs beinhalten, repliziert werden, stellt dies u.U. einen enormen Replikationsaufwand dar. Wie auch schon früher erwähnt: „Steter Tropfen höhlt den Stein“. Wenn wir diese Tatsache also umgehen können, sollten wir dies auch tunlichst vermeiden.

Das altbekannte Konzept „A – G – DL – P“ (Account – Global Group – Domain-local Group – Permissions) gilt also seit Windows NT und auch bis und mit Windows Server 2008 – nur sehen die meisten System-Administratoren immer nur den viel zu fest propagierten Vorteil darin, dass auf diese Weise eine Berechtigungsvergabe über Domänengrenzen hinweg möglich ist. Das stimmt zwar, ist jedoch nicht der Hauptvorteil. Nachfolgend ist ein Beispiel einer Gruppenverschachtelungs-Strategie über Domänengrenzen hinweg abgebildet:

 

A G DL P über Domänengrenzen hinweg

Hinweis

Ich bin ein absoluter Verfechter von mehr als einer Domäne in einer Gesamtstruktur und versuche möglichst, so unpolitisch wie es geht, nur eine Domäne zu empfehlen. Dies gelingt zwar nicht immer – aber es gibt nur selten einen Grund für die Erstellung einer Multi-Domain Gesamtstruktur, den ich gelten lassen könnte und nicht aufgrund politischer Entscheide erfolgt. Wenn dies nun das einzige Argument für „ A G DL P“ sein sollte, dann könnte in einer Ein-Domänen-Umgebung darauf verzichtet werden. Es gibt jedoch weitere Gründe dafür, welche ich im Anschluss genauer erörtern möchte.

Eine globale Gruppe ist als reine Benutzergruppe zu sehen. Diese fasst demnach Benutzerkonten zusammen, welche aus irgendwelchen Gründen zusammengehören (z.B. aufgrund der Abteilungsmitgliedschaft, Funktionsbereichen, etc.). Eine domänenlokale Gruppe hingegen, fasst eine Ressource und deren Berechtigungen zusammen. Bei domänenübergreifenden Verknüpfungen zwischen Benutzern und einer Ressource, könnte man dies auch wie folgt sehen: „Der Benutzer besteigt ein Flugzeug (globale Gruppe), um von einem Land (Domäne) in ein anderes Land zu fliegen, zwischen welchen es ein Handelsabkommen (Vertrauensstellung) gibt. Um dort zu landen, benötigt das Flugzeug (globale Gruppe) einen Flughafen (domänenlokale Gruppe) auf welchem auch die Einreise (Berechtigungen) geregelt ist.“. Eine globale Gruppe kann zwar in eine andere globale Gruppe verschachtelt werden – jedoch nur dann, wenn sich beide Gruppen in derselben Domäne befinden. Dies funktioniert (um beim vorigen Beispiel zu bleiben) auch bei einem Space-Shuttle, dass auf den „Rücken“ eines Jumbo-Jets montiert wird, um wieder nach Florida zu fliegen. Bis jetzt habe ich jedoch noch nie ein Flugzeug auf einem anderen landen sehen – da bekäme der Begriff „Flugzeugträger“ eine ganz neue Bedeutung… Eine globale Gruppe (Benutzergruppe) wird dabei auch immer in eine domänenlokale Gruppe (Ressourcengruppe) verknüpft und nie umgekehrt. Der Prophet geht auch zum Berg und der Berg kommt nicht zu ihm.

Gehen wir einmal weg von Propheten, Flugzeugen und Flughäfen und schauen uns einmal in einem praxisgerechten Beispiel an, weshalb das „A G DL P“-Konzept auch in einer Ein-Domänenumgebung absolut sinnvoll ist:

Grundsituation

Wir haben einen freigegebenen Ordner namens „Verträge“. Auf diesen müssen Buchhaltungs-Mitarbeiter mit Lese-Rechten zugreifen können, um Rechnungen aus diesen zu erstellen. Die Sales-Mitarbeiter hingegen benötigen Vollzugriff darauf, um neue Verträge zu erstellen oder bestehende ändern oder löschen zu können.

Vorgehensweise

Erstellung eines Ordners namens „Vertraege“ und Freigabe mit den Rechten für  „Authentifizierte Benutzer“ mit „Vollzugriff“

  1. Erstellung von zwei neuen domänenlokalen Gruppen mit den Namen  „DL_Vertraege_Read“ und „DL_Vertraege_Change“. Anschliessende Vergabe der entsprechenden NTFS-Berechtigungen im Ordner „Vertraege“ (gemäss Gruppenname Lesen und Ändern)
  2. Alle Benutzer der Sales- und Buchhaltungsmitarbeiter werden in die neu erstellten globalen Gruppen namens „G_Sales“ und „G_Buchhaltung“ eingefügt
  3. Nachdem diese Vorarbeit erledigt wurde, müssen nun nur noch die Benutzer-Gruppen in die Ressourcengruppen verschachtelt werden –“G_Sales“ in „DL_Vertraege_Change“ und „G_Buchhaltung“ in „DL_Vertraege_Read“ – das ist schon alles.

Vorteil

Wenn konsequent für jede Ressource sofort die entsprechenden domänenlokale Gruppe erstellt wird (je nachdem vielleicht auch mehrere mit den gewünschten Berechtigungs-Sets, wie z.B. „Read, Change oder Full Access“), können anschliessend alle Berechtigungen einfach über „Active Directory Benutzer und –Computer“ gesteuert werden. Es wäre gar möglich, einer anderen Person das Recht zur Gruppenverwaltung zu delegieren und diese mit einer benutzerdefinierten einfachen MMC auszurüsten, um diese Aufgabe an einen Power-User zu übergeben. Keiner muss sich mehr um NTFS-Berechtigungen kümmern und alles ist sehr gut dokumentierbar – das Active Directory ist dann eigentlich fast schon Dokumentation genug und es muss in der eigentlichen Dokumentation nur noch das Konzept an sich festgeschrieben sein.

Hinweis

Im ersten Schritt des obigen Beispiels wurde der Ordner freigegeben und darauf die Berechtigung „Vollzugriff“ für „Authentifizierte Benutzer“ angewendet. In der Praxis werden Freigabeberechtigungen nicht sehr detailliert konfiguriert, da die NTFS-Berechtigungen viel detaillierter vorgenommen werden können. Dennoch sollten genau genommen auch schon die Freigabe-Rechte den Zugriff grob filtern. Die besondere Entität „Authentifizierte Benutzer“ ist dabei jedoch viel besser, als „Jeder“, da „Jeder“ auch die Domänen-Gäste (und somit auch die IIS-Konten) umfasst. Wichtig ist auch die Tatsache, dass ein Administrator auch ein authentifizierter Benutzer ist! Die beste Einstellung (im Allgemeinen) wäre demnach, der Gruppe der Domänen-Admins das Recht „Vollzugriff“ und der Gruppe der authentifizierten Benutzer das Recht „Ändern“ zuzuweisen. Dies kann jedoch je nach Grundsituation variieren.

VN:F [1.9.22_1171]
Rating: 8.1/10 (7 votes cast)
VN:F [1.9.22_1171]
Rating: +3 (from 5 votes)
Optimale Gruppenverschachtelung, 8.1 out of 10 based on 7 ratings

9 Gedanken zu “Optimale Gruppenverschachtelung

  1. Hallo, ist wirklich ein Super Artikel, ich hab bloss noch eine Frage. Wie mache ich das mit einer Domäne und zwei Standorten.

    Bsp:
    1 Standort FFM (Hauptsitz)
    2 Standort Berlin

    an beiden Standorten ist ein Supportteam, diese Supportteams sollen Domänenweit User-Passwörter zurücksetzen dürfen, aber nur an ihrem eigenen Standort Computer hinzufügen dürfen.
    Wie gehe ich bei einer solchen konstellation vor ?

    1x Globale Support Gruppe, welche die Globale Support_Berlin und Support_FFM beinhaltet ?

    Können Sie mir da ein Tipp geben ?

  2. Hi Sersch

    Klingt für mich eigentlich ganz OK – ich würde das wie folgt machen:

    – Globale Support-Gruppe für alle Niederlassungen
    – Globale Support-Gruppen pro Niederlassung (welche Mitglied der generellen Support-Gruppe sind)

    …dann…:

    – DL-Gruppe für Passwort-Rücksetzung erstellen
    – DL-Gruppe für Computerkontenerstellung erstellen

    …und zum Abschluss…:

    – den DL-Gruppen die entsprechenden Berechtigungen im AD zuweisen
    – Entsprechende globale Gruppen den DL-Gruppen zuweisen

    Grüessli

    André

  3. Hi André,
    leider werden die beiden Bilder immer noch nicht angezeigt. Wäre super wenn du das ändern könntest. Der Beitrag ist nämlich super nur ohne die Bilder etwas schwer zu verstehen :)

  4. Hallo,

    erst mal ein Lob für den sehr gut gelungenen Artikel! Ich habe dazu ein Frage:

    Wie verhält es sich, wenn in tiefer verschachtelten Verzeichnissen unterhalb der Freigabe spezielle Rechte vergeben werden sollen. Das Konzept der Gruppenverschachtelung bleibt denke ich mal gleich, aber muss man dann die Vererbung deaktivieren?

  5. Hi,

    Ich habe den Artikel genau gelesen, weil ich an einer Ordnerstruktur dran bin. Der Artikel ist ok aber ich denke er geht für meinen Fall zuweit.

    Ich habe einen Fileserver mit einer vorgegebenen Struktur bis zu Teil in die 4. Stufe. Inerhalb der Ordner soll der User nichts speichern können bzw der User kann nur im letzten Ordner speichern. Er soll auch nichts umbenennen können. Es gibt die Rechte nur lesen und auch lesen und schreiben. Es gibt 18 Usergruppen. Eine Gruppe beinhaltet alles User. 

    Wie mache ich das am besten? Es geht mir darum die bestehende Struktur zu schützen. Vorallem wegen dem Umbenennen und dem Speichern in der Struktur.

     

    Beispiel:

    Ordner1

        Unterordner1.1

        Unterordner1.2

            Unterordner1.2.1

    Ordner2

         Unterordner2.1

         Unterordner2.2

    alle Ordner können nicht umbenannt werden. Der User soll nur in den letzen Ordnern speichern können. Also kein speichern im Ordner2 oder im Unterordner1.2 möglich.

     

    Besten Dank für Deine Inputs

    Gruss Sascha

Schreib einen Kommentar