Windows-Gruppen richtig nutzen

Bereits seit der ersten Version von Windows NT kennt Microsofts professionelles Betriebssystem Benutzergruppen, die es nutzt, um Rechte und Privilegien innerhalb des Systems sowie Zugriffsrechte auf Objekte (z.B. Dateien) zu erteilen. Die Grundidee dabei ist, dass es erheblich einfacher ist, ein bestimmtes Recht einer Gruppe zuzuteilen und in diese Gruppe dann Benutzerkonten als Mitglieder aufzunehmen. Jedes Mitglied einer Gruppe erhält so die Berechtigungen, die für die Gruppe gelten. Dabei kann jeder Benutzer einer (nahezu) beliebigen Anzahl von Gruppen angehören.

In der Praxis stellt man aber immer wieder fest, dass viele Admins unsicher sind, wie sie Gruppen sinnvoll einsetzen können. Das liegt vor allem daran, dass das Gruppenkonzept im Detail erheblich komplexer ist als in der kurzen Darstellung oben. Dieser Artikel fasst daher einige Grundlagen und Empfehlungen zusammen.

So viele Arten von Gruppen!

Das größte Verständnisproblem entsteht durch die hohe Anzahl verschiedener Gruppentypen, die Windows bereithält. Diese Gruppen verhalten sich in bestimmten Zusammenhängen unterschiedlich, daher kommt nicht jeder Gruppentyp für jeden Zweck in Frage. Hier eine kurze Einordnung auf Basis der Technik seit Windows 2000 (als Active Directory eingeführt wurde).

Lokale Gruppen

Jeder Windows-Rechner verfügt über lokale Gruppen, die teilweise bereits vordefiniert sind, die man aber auch selbst erzeugen kann. Solche lokalen Gruppen existieren und wirken ausschließlich auf dem jeweiligen Computer und haben keine Auswirkung auf andere Rechner. Auch ein Ex- und Import solcher Gruppen ist nicht möglich.

Welche Gruppen es lokal gibt, kann man in der Kommandozeile feststellen mit:

net localgroup

Die Mitglieder einer bestimmten Gruppe bekommt man angezeigt, wenn man deren Namen an das obige Kommando anhängt. Je nachdem, welche Software auf einem System installiert ist, kann es durchaus eine große Anzahl solcher lokalen Gruppen geben. Manuell legt man lokale Gruppen eher selten an, aber je nach Anforderung kann auch das bisweilen vorkommen.

Drei vordefinierte Gruppen verdienen nähere Erwähnung, weil es sie auf jedem Windows-System gibt und weil sie im gesamten Rechtesystem eine tragende Rolle spielen:

• AdministratorenWer dieser Gruppe angehört, verfügt über volle Verwaltungsrechte auf dem Rechner. Ein Mitglied der “Administratoren” kann jede Systemeinstellung verändern, Software jeder Art installieren und entfernen und sich Rechte und Berechtigungen an jedem Objekt und jeder Datei verschaffen. Zwar ist es durchaus möglich, in den Berechtigungseinstellungen etwa einer Datei den Administratoren den Zugriff zu verweigern, aber als Mitglied der “Administratoren” kann ein Benutzer das immer rückgängig machen.

  Höhere Rechte als “Administrator” kann man in einem Windows-System nicht haben. Auch eine Anmeldung als “Domänen-Administrator” oder als “Organisations-Administrator” verschafft einem lokal keine Zugriffe, die man als “Administrator” nicht hätte! (Zwar vermuten sehr viele Admins, dass dies so sei, aber das ist nur ein Mythos.)

• BenutzerUm einen Rechner überhaupt verwenden zu dürfen, muss man der Gruppe “Benutzer” angehören. Dafür sorgt Windows automatisch, wenn man lokale Benutzerkonten erzeugt, weil es diese gleich in die Gruppe “Benutzer” aufnimmt. In einer Windows-Domäne wird die Gruppe “Domänen-Benutzer” auf jedem Rechner in die jeweils lokalen “Benutzer”-Gruppen aufgenommen: Nur dadurch ist es möglich, dass man sich mit einem Domänen-Benutzerkonto (standardmäßig) an jeden Rechner der Domäne anmelden kann.
• HauptbenutzerDiese Gruppe verfügt auf einem lokalen Computer bis einschließlich Windows XP über erweiterte Berechtigungen. Seit Windows Vista ist die Gruppe zwar noch vorhanden, aber sie verfügt nicht mehr über Sonderrechte.

  Mitglieder der “Hauptbenutzer” können bis Windows XP sehr viele Dinge im System verändern und haben weitgehende Schreibrechte. Dadurch entstehen erhebliche Sicherheitsprobleme, denn mit wenig Aufwand ist es einem Hauptbenutzer in der Praxis möglich, sich zum vollwertigen “Administrator” zu machen. Daher ist von der Nutzung dieser Gruppe erheblich abzuraten!

Domänenlokale Gruppen

Im englischen Original heißt dieser Gruppentyp “Domain Local Group”, in der deutschen Windows-Oberfläche ist üblicherweise von “Gruppe der lokalen Domäne” die Rede.

Es handelt sich dabei um Gruppen, die in Active Directory gespeichert sind und auf allen Rechnern derselben Domäne zur Erteilung von Berechtigungen genutzt werden können. Domänenlokale Gruppen können auch Mitglieder aus anderen Domänen aufnehmen, zu denen eine Vertrauensstellung besteht (Forest-interne Vertrauensstellung oder auch externe Vertrauensstellung); als Mitglieder lassen sich Benutzer- oder Gruppenkonten auswählen. Da dieser Gruppentyp nur in der eigenen Domäne sichtbar ist, eignet er sich zur Verwaltung von Zugriffen auf Ressourcen (z.B. Dateiserver, Druckserver, Datenbanken usw.) in der lokalen Domäne – daher der Name.

Das Windows-Gruppenkonzept sieht vor, dass man vorwiegend diesen Gruppentyp einsetzt, um in der eigenen Domäne Berechtigungen zu verwalten. Die Logik dahinter: Eine Domäne fasst üblicherweise die Ressourcen eines “Hoheitsbereichs” zusammen, und wer diesen Hoheitsbereich verwaltet, soll auch Kontrolle über die Zugriffsrechte haben. Gleichzeitig soll es aber möglich sein, auch Anwendern aus anderen, vertrauten Domänen die Nutzung einzelner Daten und Dienste zu gestatten, daher kann man in Gruppen dieser Art eben auch Konten der anderen Domänen aufnehmen. Das macht die Rechteverwaltung sehr effizient, weil man für ein bestimmtes Zugriffsrecht nur eine einzige Gruppe pflegen und berechtigen muss.

“Builtin”-Gruppen

Einen Sonderfall unter den Domänenlokalen Gruppen stellen die Gruppen im AD-Container “Builtin” dar. Hierbei handelt es sich um die Lokalen Gruppen der Domänencontroller – eigentlich sind es also gar keine Domänenlokalen Gruppen, sondern Lokale Gruppen, und daher sind sie auch nur direkt auf den Domänencontrollern sichtbar und nutzbar.

Die Builtin-Gruppen dienen dazu, Berechtigungen zu verwalten, die nur direkt auf den Domänencontrollern gelten. Wer etwa Mitglied der Gruppe “Builtin\Sicherungsoperatoren” ist, darf ein Backup aller Domänencontroller ausführen – aber kein Backup anderer Computer. Es ist dabei nicht möglich, diese Berechtigung auf einzelne Domänencontroller einzugrenzen, sondern sie gelten immer auf allen DCs.

Es ist wichtig zu wissen, dass die Builtin-Gruppen ausschließlich auf Domänencontrollern gelten. In allen alltäglichen Verwaltungsaufgaben kann man den ganzen Container “Builtin” daher praktisch ignorieren, weil die Berechtigungsverwaltung für DCs eher keine Standardaufgabe ist.

Globale Gruppen

Die Globalen Gruppen sind ebenfalls in Active Directory gespeichert. Im Unterschied zu den Domänenlokalen Gruppen können sie nur Mitglieder aus der eigenen Domäne enthalten, aber keine Konten aus anderen Domänen. Dafür sind diese Gruppen aber in anderen, vertrauten Domänen sichtbar und können dort Berechtigungen erhalten oder auch in Domänenlokale Gruppen dieser anderen Domäne aufgenommen werden.

Prinzipiell ist dieser Gruppentyp dazu gedacht, Benutzerkonten nach logischen Kriterien zusammenzufassen, also etwa nach Abteilung oder nach Funktion.

Vordefinierte Gruppen dieses Typs umfassen die Domänen-Admins und die Domänen-Benutzer. Üblicherweise legt man eine größere Menge dieser Gruppen manuell an, um organisatorische Anforderungen abzudecken.

Universalgruppen

In der deutschen Windows-Oberfläche nennt sich dieser Gruppentyp “Universell”. Gruppen dieser Art können Mitglieder aus allen Domänen des Forests aufnehmen (aber nicht aus externen vertrauten Domänen!) und sind in allen Domänen des Forests sichtbar.

Damit eignet sich dieser Gruppentyp in Multi-Domänen-Forests dazu, Benutzer domänenübergreifend zusammenzufassen und ihnen in beliebigen Domänen des Forests Berechtigungen zu erteilen. Nun könnte man meinen, dieser Gruppentyp sei damit ja auch der flexibelste und deshalb nur noch mit dieser Sorte arbeiten. Davon ist aber abzuraten: Einerseits erzeugen diese Gruppen einen gewissen Overhead, denn im Unterschied zu den anderen Typen speichert Active Directory sie nicht innerhalb der Domäne, sondern im Global Catalog. Andererseits ist dieser Gruppentyp in großen Umgebungen mit mehr als einer Domäne schwer abzugrenzen – eben deshalb, weil er Mitglieder aus allen Domänen enthalten und gleichzeitig in allen Domänen Berechtigungen haben kann. Eine solche Gruppe zu verändern, ist daher immer ein planungs- und analyseintensiver Schritt.

Seit Exchange 2007 allerdings haben Universalgruppen eine besondere Funktion: Exchange akzeptiert nur Gruppen dieses Typs als Verteilergruppen (jedenfalls wenn man sie neu anlegt). Der Grund dafür liegt wiederum in Multi-Domänen-Forests, in denen nur die Mitglieder von Universalgruppen mit Sicherheit in jeder Teildomäne des Forests auflösbar sind.

Zu den vordefinierten Gruppen dieses Typs gehören die “Organisations-Admins” (englisch: “Enterprise Admins”) und die “Schema-Admins”.

Pseudo-Gruppen

Neben diesen “normalen” Gruppen, die man (zum größten Teil) manuell erzeugen kann und deren Mitgliedschaft durch die Administratoren ausdrücklich gepflegt wird, gibt es noch einen weiteren, völlig anderen Gruppentyp. Die Pseudo-Gruppen (oft auch als “Systemgruppen” bezeichnet) werden ausschließlich vom Betriebssystem verwaltet, eine manuelle Änderung der Mitgliedschaft ist nicht möglich. In den meisten Fällen entscheidet die Art, wie ein Anwender sich anmeldet, über die Mitgliedschaft. An solche Gruppen werden innerhalb des Betriebssystems, aber durchaus auch an anderen Stellen, Berechtigungen für spezielle Zwecke vergeben.

Einige Beispiele:

• Authentifizierte Benutzer: Diese Gruppe enthält immer die Anwender, die aktuell gültig an einem System angemeldet sind. Seit Windows XP, Service Pack 2, ist sie funktional identisch mit der Gruppe “Jeder”. Nicht enthalten sind anonyme Anwender, die ohne Anmeldung auf einen Dienst zugreifen, beispielsweise bei einem Webserver.
• Interaktiv: In dieser Gruppe sind alle Benutzer Mitglied, die sich direkt lokal (= “interaktiv”) an ein System angemeldet haben. Dadurch lassen sich die momentanen lokalen Benutzer eines Systems zur Berechtigungsvergabe identifizieren. Nicht enthalten sind Benutzer, die über das Netzwerk einen Dienst nutzen (z.B. beim Zugriff auf einen Dateiserver).
• Netzwerk: Zu dieser Gruppe zählen angemeldete Benutzer, die nur über das Netzwerk auf einen Dienst zugreifen. Nicht enthalten sind lokal angemeldete Anwender.
• Ersteller/Besitzer: Dies ist eigentlich keine Gruppe, sondern ein Platzhalter für Berechtigungen. Darüber lässt sich festlegen, dass der Benutzer, der ein Objekt (z.B. eine Datei) erzeugt hat, bestimmte Rechte an diesem Objekt erhalten soll.
• Selbst: Auch dies ist eigentlich keine Gruppe, sondern ebenfalls ein Platzhalter, der aber nur in Active-Directory-Berechtigungen auftaucht. Mit diesem Platzhalter lassen sich Berechtigungen für den Fall verwalten, dass ein Konto auf sein eigenes AD-Objekt zugreift. Öffnet also etwa die Benutzerin “Ute” im AD-Verwaltungsprogramm das Userobjekt “Ute”, dann greift für sie die Berechtigung “Selbst”, denn es ist ja ihr eigenes Objekt. Diesen Kniff nutzt Active Directory für ein paar Standardberechtigungen; so kann z.B. jeder Anwender standardmäßig seine eigene Telefonnummer in Active Directory bearbeiten.

An vielen Stellen erkennt man solche Gruppen an dem Präfix “NT-AUTORITÄT”.

Wie Berechtigungen funktionieren

Windows verwaltet alle Berechtigungen auf der Basis von Security Identifiers (SID). Jedes Sicherheitsobjekt – also jedes Benutzer-, Computer- oder Gruppenkonto – hat einen solchen eindeutigen SID, der sich niemals ändert. Auf diese Weise ist es möglich, ein Objekt umzubenennen, ohne dass es seine Berechtigungen verliert.

Bei der Anmeldung ans System erhält jeder Benutzer ein “Access Token”, das u.a. seinen eigenen SID und die SIDs aller Gruppen enthält, in denen er Mitglied ist. Dieses Access Token bildet dann seinen Berechtigungsausweis für alle Zugriffe. Da es nur bei der Anmeldung erzeugt wird, sind alle Änderungen an Gruppenmitgliedschaften, die während der laufenden Arbeitssitzung erfolgen, wirkungslos. Erst bei der nächsten Anmeldung wird ein neues Access Token erzeugt, das die dann gültigen Mitgliedschaften umfasst.

Versucht der Anwender, auf bestimmte Daten zuzugreifen, so überträgt Windows im Hintergrund die genaue Zugriffs-Anforderung und das Access Token an den jeweiligen Dienst. Der Dienst prüft dann die Berechtigungen des Objekts (niedergelegt in der “Access Control List”, ACL), ob für eine oder mehrere SIDs im Access Token des Benutzers die passenden Rechte hinterlegt sind. Nur wenn die Zugriffs-Anforderung durch die vorhandenen Berechtigungen genau erfüllt werden kann, gibt der Dienst den Zugriff frei, anderenfalls verweigert er ihn (Alles-oder-nichts-Prinzip). Fordert ein Anwender also etwa einen Schreib- und Lesezugriff an, aber seine Berechtigungen erlauben nur den Lesezugriff, dann kann er gar nicht auf das Objekt zugreifen. (In der Praxis merkt man das manchmal nicht, weil eine Applikation in diesem Fall einen erneuten Zugriff nur zum Lesen versuchen könnte.)

Um sich das Access Token anzusehen, kann man das Kommandozeilentoll “whoami” nutzen, das seit Windows Vista immer installiert ist (in früheren Versionen kann man es aus den Support Tools nachinstallieren). Die effektiven Gruppenmitgliedschaften sieht man etwa mit:

whoami /groups

Alle Einträge des Tokens (einschließlich des Benutzer-SID und der Privilegien auf dem eigenen System) zeigt:

whoami /all

Das A-G-DL-P-Prinzip

Das Gruppenkonzept von Windows und Active Directory wurde nach einem bestimmten Prinzip entworfen, das es Administratoren auch in komplexen Umgebungen erlauben soll, Berechtigungen auf Ressourcen strukturiert und effizient zu verwalten. Dabei orientiert sich Windows an einem rollenbasierten Zugriffsmodell (und zwar schon seit 1993 – viele andere Hersteller haben dieses Modell erst vor Kurzem für sich entdeckt).

Das Prinzip ist bekannt als das “A-G-DL-P-Prinzip” (oder kurz auch „AGDLP“):

• Accounts (Benutzerkonten)
• go in Global Groups (Globale Gruppen)
• nested in Domain Local Groups (Domänenlokale Gruppen)
• that are granted Permissions (Berechtigungen)

Das Konzept wird oft missverstanden, daher soll ein Beispiel helfen.

Das A-G-DL-P-Prinzip der Gruppen- und Rechteverwaltung

• Links finden sich die Accounts der Anwender. Diese sind nach logischen Kriterien in Globalen Gruppen zusammengefasst, die hier die Zugehörigkeit zu einer Abteilung, aber auch die Funktion in einem bestimmten Projekt widerspiegeln.
• Ganz rechts finden sich die Ressourcen, für die die Zugriffsrechte verwaltet werden sollen: Die CRM-Datenbank (Zugriff erforderlich für den Vertrieb), ein Drucker (Zugriff für alle möglich) und eine bestimmte Projekt-Datei (Leserechte für die Technik und voller Zugriff für die Projektleitung).
• Der Kniff ist nun: Die DL-Gruppen erzeugt man passend zu den jeweiligen Zugriffsrechten, idealerweise mit sprechenden Namen. Da es für die CRM-Datenbank und den Drucker in diesem Fall nur jeweils ein unterschiedenes Recht gibt, reicht jeweils eine Gruppe aus. Für die Projektdatei sind aber zwei Zugriffsarten zu unterscheiden, daher gibt es für jedes Recht eine eigene Gruppe.
• Nur diese DL-Gruppen erhalten nun die passenden Berechtigungen. Die Berechtigungsliste (ACL) bleibt dadurch sehr kurz und muss nach diesem Konzept nie wieder verändert werden.
• Als Letztes erfolgt die Zuweisung der Globalen Gruppen zu den jeweiligen Domänenlokalen Gruppen, und zwar abhängig davon, welches Zugriffsrecht die Gruppe haben soll.

Ein noch deutlicheres Beispiel aus der Praxis: Eine komplexere Applikation (nennen wir sie “App-L”) soll für den Zugriff auf einem Terminalserver mit Berechtigungen versehen werden. Zu der Applikation gehören die Programmdateien, eine Datenbank und eine Freigabe auf einem Dateiserver. Die Mitglieder des Vetriebs und des Vorstands sollen diese Applikation nutzen können.

• Zunächst richtet man eine Domänenlokale Gruppe für die Zugriffsberechtigungen ein. Nennen wir sie “DL-App-L-Benutzer”.
• Diese Gruppe (und nur diese!) erhält die Lese- und Ausführungsberechtigung für die Programmdateien auf dem Terminalserver. Ebenso erhält diese Gruppe Zugriffsrechte für die Datenbank und für die Dateifreigabe.

  Mit diesem Schritt sind alle Berechtigungen vollständig und endgültig bearbeitet!

• In die Gruppe “DL-App-L-Benutzer” nimmt man nun die beiden Globalen Gruppen “G-Vertrieb” und “G-Vorstand” auf.

Aufgrund dieses Modells haben künftig alle Mitglieder der Gruppen “G-Vertrieb” oder “G-Vorstand” die nötigen Rechte, um mit der Applikation “App-L” zu arbeiten. Die Berechtigungen muss man nun nie wieder anpassen, auch wenn neue Vertriebsmitarbeiter hinzukommen oder Vorstandsmitglieder das Unternehmen verlassen: Es reicht aus, die Mitgliedschaft in den beiden Globalen Gruppen zu pflegen.

Best Practice und Grenzen

Die Gruppen- und Berechtigungsverwaltung nach dem A-G-DL-P-Prinzip erfordert umfangreiche Analyse und Planung. Wer sie aber beherzigt, wird mit einem sehr gut wartbaren Berechtigungskonzept belohnt, das darüber hinaus sehr einfach zu dokumentieren ist. Zumindest für zentrale und komplexe Ressourcen ist die Anwendung dieses Modells sehr zu empfehlen. Auch in Migrationen hat sich das Prinzip sehr bewährt, weil es nur wenige Änderungen erfordert, wenn sich Systeme oder Domänen mal ändern.

In der Alltagsadministration gibt es oft “sofortige” Zugriffs-Anforderungen, die sich nach dem Konzept nicht schnell umsetzen lassen. Wo man hier die Grenze zieht, muss man selbst entscheiden. Die Erfahrung zeigt aber, dass die Ad-hoc-Verwaltung sehr schnell zu einem ausufernden Geflecht von Berechtigungen führt, das kaum noch nachvollziehbar ist.

Ein Nachteil des Konzepts tritt in sehr großen Umgebungen zutage, denn dort führt es schnell zu einer sehr großen Zahl von Gruppen und von Gruppenmitgliedschaften. Da das Access Token in seiner Größe begrenzt ist, kann ein Benutzer nicht gleichzeitig in mehr als ca. 1015 Gruppen Mitglied sein (vgl. Knowledge-Base-Artikel 328889). Hier können Variationen des Konzepts evtl. helfen. Eine andere Methode in solchen Umgebungen besteht darin, eigene Domänen für Anwender- und Ressourcenobjekte zu erzeugen. In diesem Fall “leben” die Domänenlokalen Gruppen in der Ressourcen-Domäne und blähen das Access Token innerhalb der Anwenderdomäne nicht über Gebühr auf.