Die Komplexität des Konzepts der Gruppenrichtlinien resultiert aus mehreren Faktoren. Der erste ist, dass Gruppenrichtlinien unzählige Einstellungen enthalten und damit schon für sich genommen komplex sind. So wurden alleine mit dem Service Pack 2 für Windows XP mehr als 700 zusätzliche Parameter für die Steuerung des Internet Explorer hinzugefügt.
Der zweite wichtige Faktor ist die Vererbung im Zusammenhang mit der Möglichkeit, Richtlinien an verschiedenen Stellen im System zuzuordnen. Richtlinien können Standorten, Domänen und organisatorischen Einheiten zugewiesen werden. Da organisatorische Einheiten wiederum verschachtelt sein können, kann es davon mehrere Ebenen gegen.
Das Vererbungskonzept wird zusätzlich dadurch komplex, dass man die Vererbung manuell steuern und außerdem mehrere Richtlinien, auch mit unterschiedlichen Sicherheitseinstellungen, bei einem Standort, einer Domäne oder einer organisatorischen Einheit zuweisen kann.
Ein weiterer Faktor sind die bereits im ersten Teil der Serie beschriebenen Abhängigkeiten von Systemversionen, die in den Gruppenrichtlinien unter Umständen zu beachten sind. Nicht alle Einstellungen gelten auch für alle Systeme. Das kann im Einzelfall zu weiteren Herausforderungen führen.
Dennoch lassen sich die Gruppenrichtlinien bei richtigem Design in den Griff bekommen. Zu beachten ist aber, dass man dabei immer Kompromisse schließen muss. So bedeutet die nachfolgend beschriebene Verwendung mehrerer GPOs auch, dass das Laden und Verarbeiten der Richtlinien beim Systemstart etwas länger dauern kann. Dafür wird das Risiko von unübersichtlichen Richtlinien, bei denen man im Extremfall am Ende nicht einmal mehr weiß, welche Einstellungen nun wo angewendet werden, minimiert.
Die Zuordnung von Gruppenrichtlinien
Die Zuordnung von Gruppenrichtlinien – also die Verknüpfung eines GPOs (Group Policy Objects) mit einem Container – kann an verschiedenen Stellen erfolgen. Die oberste Ebene sind Standorte, dann kommen die Domänen und schließlich organisatorische Einheiten.
Gruppenrichtlinien vererben sich von oben nach unten. Es werden also erst die Richtlinien für Standorte, dann für Domänen und anschließend die für organisatorische Einheiten verarbeitet, wobei bei letzteren auch die hierarchische Struktur von organisatorischen Einheiten beachtet wird. Dieser Ansatz bedeutet, dass Einstellungen, die beispielsweise für einen Standort vorgenommen wurden, durch andere Werte für den gleichen Parameter auf der Ebene von Domänen oder organisatorischen Einheiten überschrieben werden. Die wichtigste Gruppenrichtlinie ist also die bei der niedrigsten Ebene der organisatorischen Einheiten.
Dieses Konzept macht Sinn. Man kann die allgemeinen Festlegungen auf der Ebene von Domänen vornehmen. Diese werden gegebenenfalls durch spezielle Festlegungen für untergeordnete Container überschrieben. Das beste Beispiel dafür sind die beiden Standard-Richtlinien Default Domain Policy und Default Domain Controllers Policy. Die erste legt generelle Regeln für alle Systeme in der Domäne fest, die zweite überschreibt einige Einstellungen speziell für die im Container Domain Controllers verwalteten Systeme.
Beim Design sollte man diese Grundstruktur nutzen. Die erste Überlegung ist, ob man überhaupt auf der Ebene von Standorten mit Gruppenrichtlinien arbeiten sollte. Falls es keine spezifischen Einstellungen für Standorte gibt, lautet die Antwort hier ganz klar „nein“, weil man die Komplexität reduziert. Die Praxis zeigt, dass man Gruppenrichtlinien auf Standortebene kaum einmal benötigt. Nur wenn es Einstellungen geben sollte, die pro Standort unterschiedlich sind, sollte man solche Richtlinien definieren.
Ansonsten gilt als Grundregel, dass man sich auf Richtlinien für Domänen und untergeordnete organisatorische Einheiten beschränken sollte. Dabei werden Grundeinstellungen bei der Domäne definiert und bei untergeordneten organisatorischen Einheiten nur noch Abweichungen behandelt.
Vererbungssteuerung
Die zweite wichtige Grundregel beim Design von Gruppenrichtlinien ist, die Zuordnung von Gruppenrichtlinien so einfach wie möglich zu halten. Hier gibt es wie ausgeführt drei wichtige Einflussfaktoren:
-
Die Vererbung von GPOs kann beeinflusst werden.
-
Durch Zugriffsberechtigungen kann festgelegt werde, dass sich GPOs nur auf ausgewählte Objekte auswirken.
-
Bei einem Container können mehrere GPOs verknüpft werden. Deren Verarbeitungsreihenfolge kann anschließend gesteuert werden.
Man sollte mit allen drei Ansätzen sehr zurückhaltend umgehen. Die Vererbung von GPOs kann einerseits gezielt pro Container unterbrochen werden. Das betrifft primär organisatorische Einheiten, bei denen man so verhindern kann, dass sie Einstellungen von der Domäne oder übergeordneten Einheiten erben.
Dazu verwendet man den Befehl Vererbung deaktivieren aus dem Kontextmenü. Zu beachten ist, dass alle Einstellungen von höherer Ebene nicht übernommen werden – man muss die Parameter in der gewünschten Weise also bei der untergeordneten organisatorischen Einheit neu definieren. Genutzt werden sollte diese Option allenfalls bei speziellen Containern wie Domain Controllers oder einem für die Serverobjekte, um für diese spezielle Richtlinien anzuwenden.
Noch problematischer ist die Option Erzwungen, die sich im Kontextmenü des Containers Verknüpfte Gruppenrichtlinienobjekte bei den einzelnen GPOs findet. Damit kann man beispielsweise auf der Ebene einer Domäne festlegen, dass die Einstellungen einer Richtlinie auch auf den untergeordneten Ebenen gelten sollen. Das Vererbungskonzept wird also umgekehrt. Diese Option sollte generell vermieden werden, da sie das gesamte Modell der Gruppenrichtlinien sehr unübersichtlich macht.
Zugriffsrechte und Verarbeitungsreihenfolge
Ein weiterer kritischer Bereich ist die Sicherheitsfilterung, also die Verwendung von Zugriffsberechtigungen. Bei jedem GPO können im Bereich Sicherheitsfilterung die Gruppen, Benutzer und Computer angegeben werden, für die ein solches Objekt gelten soll.
Damit kann man beispielsweise steuern, dass bestimmte Richtlinien nur für spezielle Gruppen von Benutzern wie Führungskräfte, IT-Administratoren oder auch für ausgewählte Computer wie Server angewendet werden.
Wenn man das aber über die Zugriffsberechtigungen macht, ist es kaum noch nachvollziehbar, wie sich welche Richtlinien auswirken. Es macht mehr Sinn, mit sauber strukturierten organisatorischen Einheiten beispielsweise auch für Server zu arbeiten und dort gezielt spezielle GPOs zu definieren, die gegebenenfalls auch Einstellungen von höherer Ebene überschreiben und beispielsweise strengere oder weniger einschränkende Zugriffsberechtigungen festlegen.
Ebenfalls nicht unproblematisch ist die Zuordnung mehrerer GPOs zu einem Container. Man könnte diese über Zugriffsberechtigungen nun für verschiedene Gruppen von Benutzern oder Computern anwenden. Man kann aber auch die Verarbeitungsreihenfolge festlegen, wobei hier – analog zur Vererbung – gilt, dass die zuletzt verarbeitete Gruppenrichtlinie die wichtigste ist. Die Verknüpfungsreihenfolge wird dabei als Rangfolge interpretiert, ist also bezüglich der Reihenfolge der Verarbeitung von unten nach oben zu lesen. Mit beiden Ansätzen sollte man sehr vorsichtig sein, da auch hier wieder gilt, dass das Risiko der Unübersichtlichkeit schnell anwächst.
Wenn überhaupt, dann könnten für ausgewählte Benutzergruppen GPOs mit speziellen Benutzerrechten definiert werden, um nicht zusätzliche organisatorische Einheiten definieren zu müssen. Denn hier gibt es eventuell einen Gestaltungskonflikt zwischen den Gruppenrichtlinien und dem Active Directory. Für Gruppenrichtlinien macht eine sehr differenzierte Strukturierung von organisatorischen Einheiten Sinn, während sie beim Active Directory-Design nicht immer erwünscht ist.
Mehrere GPOs sollte man zu einem Container nur zuordnen, wenn diese sich nicht überlappen. So könnte man mit einer Richtlinie die Festlegungen für den Internet Explorer steuern, mit einer anderen dagegen die Konfiguration des Desktops.
Mehr oder weniger Richtlinien?
Das führt automatisch auch zur Frage, ob man mit mehr oder weniger Richtlinien arbeiten sollte. Die Erfahrung zeigt, dass eine Aufteilung von Richtlinien grundsätzlich die bessere Lösung ist. Man kann mit Richtlinien für bestimmte Bereiche der Systemkonfiguration arbeiten, also beispielsweise den Internet Explorer, Desktop-Richtlinien und Sicherheitsrichtlinien, wobei letztere für verschiedene Arten von Systemen in unterschiedlicher Weise definiert werden müssen.
Diese grundlegenden Richtlinien werden auf der Ebene der Domäne definiert. Anschließend kann man, soweit erforderlich, für untergeordnete organisatorische Einheiten noch spezielle Richtlinien erstellen. Dort kann man entweder nur eine Richtlinie definieren, die alle übergeordneten Richtlinien modifiziert oder mehrere Richtlinien für spezielle Zwecke. Solche Richtlinien braucht man beispielsweise für Domänencontroller, aber auch für Administratoren und Helpdesk-Mitarbeiter.
Wenn man sich an die genannten Überlegungen zum Design von Gruppenrichtlinien hält, kann nicht mehr so viel schief gehen. Die wichtigste Regel ist in jedem Fall, dass man mit wenigen Konzepten durchgängig arbeitet und nicht durch Sonderfälle zusätzliche Komplexität schafft.
Modellierung und Ergebnisse
Best Practices
Add-Ons zu Gruppenrichtlinien und weitere Tools