Ein Modell für die effiziente Nutzung von Gruppenrichtlinien

Das größte Risiko bei Gruppenrichtlinien liegt darin, dass man sehr viel Arbeit in die Einrichtung steckt, ohne den gewünschten Erfolg zu erzielen, und leicht den Überblick verliert. Um das zu vermeiden, muss man sich beim Design von Gruppenrichtlinien an bestimmte Vorgehensweise oder „Best Practices“ halten.

Die Basis

Da Gruppenrichtlinien nur Domänen, organisatorischen Einheiten und Standorten zugeordnet werden können, ist die Strukturierung der Active Directory-Infrastruktur entscheidend für die Effizienz der Arbeit mit Gruppenrichtlinien. Das heißt nicht, dass man sich beim Design des Active Directory primär an den Gruppenrichtlinien orientieren muss. Aber um eine optimale Lösung zu finden, sollten sie mit beachtet werden.

Eine sinnvolle Struktur des Active Directory ist in der Regel auch eine relativ gute Basis für die Gruppenrichtlinien. Wer das Active Directory sauber strukturiert, hat zumindest eine Basis für eine effiziente Umsetzung von Gruppenrichtlinien, bei der es allerdings meist noch zwei größere Herausforderungen gibt:

• Die Strukturen des Active Directory sind oft zu grob, um effizient mit Gruppenrichtlinien arbeiten zu können.

• Deshalb werden für einen effizienten Einsatz von Gruppenrichtlinien in der Regel ergänzende Strukturen benötigt, wie sie beispielsweise mit dem Container Domain Controllers in Einzelfällen auch vorhanden sind.

Bei der Arbeit mit Gruppenrichtlinien ist zu beachten, dass es sich um ein Konstrukt handelt, das sich in erster Linie an Domänen orientiert. Eine Vererbung über die Grenzen von Domänen in einem hierarchisch aufgebauten Forest mit mehreren Domänen ist nicht möglich – geschweige denn, über die Grenzen von Forests hinweg, selbst wenn mit Cross-Forest-Trusts gearbeitet wird.

Theoretisch können zwar auch GPOs (Group Policy Objects, Gruppenrichtlinienobjekte) aus anderen Forests zugeordnet werden. In der Praxis macht das aber wenig Sinn, weil der Verarbeitungsaufwand bei der Nutzung von GPOs über Domänengrenzen zu hoch ist. Um aber einheitliche Standardrichtlinien in mehreren Domänen zu erhalten, kann man in einer Domäne – sinnvollerweise der Top-Level-Domäne im Forest – ein GPO erstellen, das nicht verknüpft ist, sondern nur die Informationen enthält, die sich in allen Standardrichtlinien finden sollen. Dieses kann gesichert und anschließend in jeder Domäne in die definierte Standardrichtlinie eingelesen werden. Die verwendete Standardrichtlinie ist dabei – so viel vorab – sinnvollerweise nicht die Richtlinie Default Domain Policy.

In einem Forest gibt es eine oder mehrere Domänen, innerhalb derer der größte Teil des Managements von Gruppenrichtlinien erfolgt. Pro Domäne gibt es die zwei bekannten Standardrichtlinien:

• Default Domain Policy ist die Standardrichtlinie, die für alle Clients und Server in einer Domäne gilt.

• Default Domain Controllers Policy ist der organisatorischen Einheit Domain Controllers zugeordnet und enthält Einstellungen speziell für die Domänencontroller.

Zu beachten ist, dass sich die Richtlinie Default Domain Policy auch auf den Ordner Domain Controllers auswirkt, was sich im Register Gruppenrichtlinienvererbung in der GPMC gut erkennen lässt (Bild 1). Das ist deshalb wichtig, weil sich Änderungen in der Richtlinie damit auch auf Domänencontroller auswirken, was keineswegs immer erwünscht ist.

Sobald die Domänen etwas größer werden, stößt man aber an die Grenzen für die effiziente Nutzung von Gruppenrichtlinien. Schon bei einigen Dutzend Benutzern wird man nicht mehr mit einer einheitlichen Richtlinie auskommen, von speziellen Gruppen wie Administratoren und Operatoren einmal ganz abgesehen. Wenn es in einer Domäne Hunderte oder Tausende von Benutzern gibt, muss man in jedem Fall weiter strukturieren. Das Mittel hierfür sind die organisatorischen Einheiten.

Genau das ist auch der Bereich, in dem man die Strukturen des Active Directory unter Umständen für Gruppenrichtlinien anpassen muss. Denn oft wird für die normale Administration nicht mit organisatorischen Einheiten gearbeitet. Sie machen auch manches schwieriger wie beispielsweise die Konfiguration von Provisioning-Lösungen, die in diesem Fall Benutzer und Gruppen in einer Vielzahl organisatorischer Einheiten anlegen müssen statt nur in einer oder wenigen Domänen. Auf der anderen Seite wird der Implementierungsaufwand für Gruppenrichtlinien deutlich geringer, wenn man mit organisatorischen Einheiten arbeitet, um Benutzer mit gleichen Bedürfnissen zusammenzufassen. Dabei ist die Strukturierung nach dem organisatorischen Aufbau des Unternehmens ein Ansatz, der eigentlich immer funktioniert. Das kann zwar bei organisatorischen Änderungen einigen Anpassungsaufwand verursachen, ist aber in der Regel noch gut beherrschbar. Zudem gilt es auch hier einen Mittelweg zwischen der genauen Abbildung und der Nutzbarkeit zu finden. Grundsätzlich gilt, dass man organisatorische Strukturen nur soweit abbilden muss, wie sich daraus auch Änderungen für die Gruppenrichtlinien ergeben.

Falls man für andere Anforderungen eine detailliertere Strukturierung vorgenommen hat, ist das wiederum kein Problem, da sich Gruppenrichtlinien vererben. Im Zweifelsfall werden sie nur auf höherer Ebene organisatorischer Einheiten und nicht auf der niedrigsten Ebene zugeordnet.

Spezielle Anforderungen

Es gibt eine Reihe spezieller Anforderungen, die im Active Directory für eine effiziente Umsetzung von Gruppenrichtlinien abgebildet werden sollten.

Das bereits erwähnte Beispiel ist die organisatorische Einheit Domain Controllers. In ihr werden die Informationen zu Domänencontrollern abgelegt. Im Standardfall finden sich dagegen alle anderen Computerkonten im Container Computers, während die Benutzer in Users angelegt werden. Für kleine, einfache Netzwerke ist das eventuell ausreichend, für mittlere und größere Umgebungen aber auf keinen Fall.

Daher muss man sowohl für Computer als auch für Benutzer noch einige Anpassungen vornehmen. Bei den Computern geht es dabei vor allem um die nachfolgenden Gruppen von Systemen:

• Server, die nicht Domänencontroller sind. Die Computerobjekte für diese sollten in eigenständigen Containern angelegt werden. Je nach Zahl und Art der Server wird man dabei entweder mit nur einem solchen Container arbeiten oder unterhalb eines Containers Servers weitere Container für die verschiedenen Gruppen von Servern anlegen. Mit diesem Ansatz lässt sich eine Richtlinie Server Policy für alle Server anlegen. In den untergeordneten Containern werden nur noch Anpassungen für spezielle Anforderungen der einzelnen Gruppen von Servern vorgenommen.

• Rechner von Administratoren und Operatoren sollten auch gesondert behandelt werden. Dort sind restriktive Einschränkungen in der Regel nicht wünschenswert. Da es – wie weiter unten erläutert wird – ohnehin erforderlich ist, für die entsprechenden Benutzer eine eigene organisatorische Einheit anzulegen, sollten die Computerkonten der von Administratoren und Operatoren genutzten Rechner in derselben OU angelegt werden. Gleiches gilt für Testsysteme, soweit diese Teil des Forests sind und nicht in einer gesonderten Active Directory-Infrastruktur betrieben werden.

• Systeme in Schulungsräumen und andere Rechnergruppen mit sehr speziellen Anforderungen wie beispielsweise Kiosk-Systeme sollten ebenfalls in eigenen organisatorischen Einheiten abgelegt werden.

• Schließlich stellt sich noch die Frage, ob weitere Unterscheidungen beispielsweise für Notebooks vorgenommen werden müssen. Da es vergleichsweise wenige Einstellungen gibt, die sich bei solchen Systemen unterscheiden, dürfte das in den meisten Fällen nicht erforderlich sein. Zudem ist die Nutzung von Notebooks oft auf bestimmte Bereiche des Unternehmens wie den Vertrieb beschränkt, so dass man die entsprechenden Anpassungen für diese organisatorischen Einheiten oder sogar Domänen – je nach Strukturierung des Active Directory – vornehmen kann. Falls das nicht geht und solche Einschränkungen erforderlich sind, muss man über die Sicherheitsfilterung arbeiten.

Neben den Computern gibt es auch Benutzer mit speziellen Anforderungen. Auch hier finden sich einige typische Fälle, die spezielle Strukturen im Active Directory erforderlich machen:

• Die wichtigsten sind Administratoren und Operatoren. Gerade in den Fällen, in denen die ystemsteuerung und andere Funktionsbereiche für „normale“ Benutzer stark eingeschränkt werden, muss für Administratoren und Operatoren mehr Handlungsspielraum sichergestellt werden. Zu diesem Zweck sollten, wie oben schon kurz angerissen, in oder mehrere organisatorische Einheiten definiert werden. Das ergibt sich allerdings schon fast automatisch, wenn man das Active Directory entsprechend der Aufbauorganisation strukturiert.

• Ebenfalls wichtig sind Benutzer in den Fachbereichen, die etwas höhere Berechtigungen benötigen, weil sie einzelne operative Aufgaben wie das Druckermanagement oder das Zurücksetzen von Kennwörtern übernehmen und dafür mehr Berechtigungen benötigen als andere Benutzer.

• Ein anderes Beispiel sind spezielle Benutzergruppen wie Softwareentwickler und die von ihnen verwendeten Geräte. Soweit man deren Anforderung nach mehr Zugriffsrechten auf den Entwicklungssystemen, als „normalen“ Benutzern gewährt werden, nicht über die organisatorischen Einheiten abfangen kann, muss man ebenfalls mit der Sicherheitsfilterung arbeiten. In den meisten Fällen sollte man hier aber über die Erstellung geeigneter organisatorischer Einheiten eine ausreichende Differenzierung schaffen können.

Die Anzahl spezieller Strukturen hält sich letztlich in Grenzen. Man muss aber in jedem Fall überprüfen, ob die Strukturen des Active Directory den Anforderungen, die sich durch den Wunsch nach einer effizienten Nutzung von Gruppenrichtlinien ergeben, noch angepasst werden müssen.

Die Nutzung der Sicherheitsfilterung

Nicht alle Situationen, in denen unterschiedliche Einstellungen über Gruppenrichtlinien gesetzt werden müssen, lassen sich über die Definition von organisatorischen Einheiten abdecken. In einigen Fällen muss man für Benutzer oder Computer in der gleichen OU unterschiedliche Festlegungen über Gruppenrichtlinien setzen.

Dazu kann die so genannte Sicherheitsfilterung verwendet werden. Die Ergebnisse werden in der GPMC im Register Delegierung bei den Eigenschaften eines GPOs zusammenfassend angezeigt (Bild 2). Die Konfiguration erfolgt im Register Bereich. Dort findet sich der Abschnitt Sicherheitsfilterung, in dem Gruppen, Benutzer und Computer hinzugefügt und entfernt werden können (Bild 3).

Bei den Standardrichtlinien sind die Gruppen Domänen-Admins und Organisations-Admins im Register Delegierung als Administratoren definiert worden, während die Gruppe Authentifizierte Benutzer die Zugriffsberechtigungen über die Sicherheitsfilterung erhalten hat. Diese Gruppe umfasst sowohl die authentifizierten Benutzer als auch die authentifizierten Computer! Ein Computer muss sich ja ebenfalls am Active Directory authentifizieren, was im Hintergrund mit einem automatisch generierten Kennwort erfolgt.

Daher muss man im Zusammenspiel von Prioritäten für Richtlinien und einer speziellen Sicherheitsfilterung für ausgewählte Gruppen entsprechende Anpassungen vornehmen. Mit der Sicherheitsfilterung kann beispielsweise für eineGruppe Fachbereichs-Operatoren festgelegt werden, dass diese eine spezielle Richtlinie verwenden darf. Über die Priorisierung kann allerdings nur die Reihenfolge von GPOs, die dem gleichen Container – also einer OU oder Domäne – zugeordnet sind, angepasst werden. Dagegen wird die Standard-Verarbeitungsreihenfolge Standort – Domäne – OU nicht angepasst, aus der sich ergibt, dass Richtlinien untergeordneter OUs die höchste Priorität haben, weil damit Einstellungen von zuvor schon verarbeiteten Richtlinien überschrieben werden können.

Die Verknüpfungsreihenfolge wird im Register Verknüpfte Gruppenrichtlinienobjekte bei einem Container modifiziert. Die höchste Priorität hier bedeutet, dass die Richtlinie zuletzt verarbeitet wird und damit gegebenenfalls gleichartige Einstellungen anderer verknüpfter GPOs überschreibt.

Das AD-Design entscheidet

Nimmt man diese Punkte zusammen so wird deutlich, dass das Active Directory-Design entscheidend dafür ist, wie effizient sich Gruppenrichtlinien nutzen lassen. Je mehr mit speziellen Gruppen, der Sicherheitsfilterung und der Priorisierung über die Verknüpfungsreihenfolge gearbeitet werden muss, desto komplexer und unübersichtlicher wird das Konzept der Gruppenrichtlinien.

Die Erstellung organisatorischer Einheiten innerhalb größerer Domänen und das Anlegen spezieller OUs für Server oder die IT-Administratoren bedeutet vergleichsweise wenig Aufwand, auch wenn beim Erstellen von Benutzern jeweils die richtige Zuordnung erfolgen muss. Das ist bei der Arbeit über Active Directory-Benutzer und - Computer aber ohnehin kein Problem und lässt sich auch über Skripts einfach umsetzen.

Etwas aufwändiger ist die Zuordnung von Computern zu speziellen Gruppen. Wenn etwa alle Notebooks von einer speziellen Richtlinie erfasst werden sollen, muss man die entsprechende Gruppe manuell pflegen. Bei Computerkonten, die in speziellen OUs stehen sollen – Server sind das beste Beispiel – sollte man die Konten definieren, bevor man den Rechner in die Domäne aufnimmt. Damit kann man einfach steuern, wo das Konto angelegt wird.

Der richtige Umgang mit Gruppenrichtlinien

Mit der Erstellung der Strukturen im Active Directory ist es aber nicht getan. Für die optimale Nutzung von Gruppenrichtlinien müssen einige weitere Regeln zur Bearbeitung und Zuordnung von GPOs beachtet werden:

• Die beiden Standard-Richtlinien Default Domain Policy und Default Domain Controllers Policy sollten auf keinen Fall verändert werden. Stattdessen sollten Änderungen in zusätzlichen Richtlinien vorgenommen werden. Das hat den Vorteil, dass man die Umgebung mit minimalem Aufwand auf den ursprünglichen Zustand zurücksetzen kann, indem man alle Verknüpfungen zu GPOs außer zu den Standardrichtlinien löscht. Die Standardrichtlinien können mit niedriger Priorität aktiv bleiben.

• Die Änderungen in Gruppenrichtlinien sollten in kleinen Häppchen erfolgen. So könnte man eine Internet Explorer-Richtlinie erstellen, in der nur die Anpassungen für den Internet Explorer erfolgen. Andere Beispiele sind Desktop-Konfigurationsrichtlinien, IPsec-Richtlinien, Authentifizierungsrichtlinien oder Richtlinien, mit denen die Authentifizierungseinstellungen oder die Einschränkungen für Dienste gesteuert werden. Von einigen dieser Richtlinien wie denen zur Einschränkung von Diensten werden ohnehin unterschiedliche Varianten für verschiedene Gruppen von Systemen benötigt. Es ist zwar grundsätzlich etwas aufwändiger, mit mehreren Richtlinien zu arbeiten, die beim Start verarbeitet werden müssen. Da die einzelnen Richtlinien aber schlank bleiben, sollte sich bei heute üblichen Netzwerkbandbreiten und Rechnergeschwindigkeiten keine inakzeptable Verzögerung ergeben. Außerdem können die Standardrichtlinien gegebenenfalls deaktiviert werden, wenn sichergestellt ist, dass alle Einstellungen über eigene Richtlinien gesetzt werden. Die Deaktivierung kann über das Kontextmenü eines GPOs erfolgen (Bild 5). Im Register Verknüpfte Gruppenrichtlinienobjekte lassen sich über das Kontextmenü auch einzelne GPOs deaktivieren.

• Standort-Richtlinien sollten nur mit Zurückhaltung genutzt werden. Nur bei Einstellungen, die pro Standort erfolgen müssen, sollten solche Richtlinien erstellt werden. Das ist aber nur selten der Fall, so dass man meist auf diesen Typ von Gruppenrichtlinien verzichten kann.

• Auch wenn es in einigen Situationen erforderlich ist, die Einstellungen zur Sicherheitsfilterung bei GPOs anzupassen, sollte man auch hier Zurückhaltung üben. Wenn man mehrere Richtlinien mit jeweils unterschiedlichen Festlegungen zur Sicherheitsfilterung bei einer Domäne oder OU benötigt, sollte grundsätzlich geprüft werden, ob man nicht besser weitere OUs mit jeweils nur einer Zuordnung einer Gruppenrichtlinie anlegt. Das gilt nicht für alle Fälle – aber Ausnahmen wie die weiter oben genannten bestätigen die Regel.

• Schließlich sollten auch Vererbungseinschränkungen nur genutzt werden, wenn es unbedingt erforderlich ist. Bei jeder OU kann im Kontextmenü der Befehl Vererbung deaktivieren ausgewählt werden, womit erreicht wird, dass keine Richtlinien von übergeordneten Containern übernommen werden. Das kann vor allem bei Containern wie Domain Controllers oder anderen Ordnern für Server, aber auch bei der OU für den IT-Bereich interessant sein, um sicherzustellen, dass es dort keine unerwünschten Einflüsse beispielsweise aus den Standardrichtlinien für die Domäne gibt. Bei verknüpften Gruppenrichtlinienobjekten kann im Kontextmenü auch konfiguriert werden, dass die Vererbung erzwungen wird. Damit werden Richtlinienparameter in untergeordneten Containern überschrieben, auch wenn die dort verknüpften GPOs eigentlich die höhere Priorität hätten. Verknüpfungen, bei denen diese Option gesetzt ist, können nicht deaktiviert werden.

Schließlich gilt es noch, alle Änderungen genau zu dokumentieren. Man muss für jedes GPO und jede Verknüpfung mit Containern für die Verwendung von Sicherheitsfiltern und anderer Festlegungen dokumentieren, was man warum gemacht hat. Der Aufwand dafür ist nicht zu unterschätzen, erhöht die Nachvollziehbarkeit von Gruppenrichtlinien aber immens.

Die konkrete Umsetzung an einem Beispiel

Nachdem die wichtigsten Regeln für die Nutzung von Gruppenrichtlinien erläutert wurden, werden nachfolgend noch einige für die Umsetzung wesentliche Punkte an konkreten Beispielen erklärt.

Der Ausgangspunkt ist eine Domäne, in der bereits wichtige organisatorische Einheiten definiert sind. Neben der Abbildung der wichtigsten organisatorischen Strukturen gibt es hier bereits spezielle OUs für die Server – mit mehreren untergeordneten OUs – und für die IT-Administration. Außerdem ist eine organisatorische Einheit Arbeitsplatzrechner vorhanden.

Ob diese erforderlich ist oder nicht, muss man im Einzelfall prüfen. Der Hintergrund für die Erstellung einer solchen OU ist, dass der spezielle Container Computers ebenso wenig wie der spezielle Computer Users in der GPMC sichtbar ist. Das liegt daran, dass es sich nicht um OUs handelt und diesen Containern daher auch keine Gruppenrichtlinien zugeordnet werden können. Um also unterschiedliche Einstellungen für verschiedene Gruppen von Computern vornehmen zu können, muss man entweder

• mit Gruppen von Computern und der Sicherheitsfilterung bei Richtlinien auf Domänenebene arbeiten,

• die Computer den OUs für die Benutzer zuordnen oder

• spezielle Strukturen für die Verwaltung von Computern erstellen.

Letzteres ist vor allem dann sinnvoll, wenn sich die Berechtigungen für Computer von denen für Benutzer unterscheiden können und man daher relativ differenzierte Berechtigungen benötigt. Außerdem kann man in diesem Fall sowohl mit GPOs für Benutzer als auch mit solchen für Computer arbeiten, was die Übersichtlichkeit erhöht. Dafür steigt allerdings auch die Anzahl der GPOs und damit der Aufwand für deren Verarbeitung.

Neue organisatorische Einheiten lassen sich übrigens direkt in der GPMC erstellen, was in der Regel aber nicht sinnvoll ist. Diese vorbereitenden Schritte sollten eher in Active Directory-Benutzer und -Computer oder mit Skripts durchgeführt werden, um auch gleich die Benutzer und Computer korrekt zuordnen zu können.

Die Erstellung der GPOs

Im ersten Schritt sollten nun die erforderlichen GPOs erstellt werden. Diese werden im Ordner Gruppenrichtlinienobjekte verwaltet. Es empfiehlt sich, Änderungen immer nur dort vorzunehmen und bei den einzelnen OUs nur die Verknüpfungen und andere OU-spezifische Einstellungen zu administrieren. Die GPMC zeigt ohnehin Warnmeldungen an, wenn versucht wird, Änderungen an einem GPO direkt dort vorzunehmen.

Die neu erstellten GPOs sollten zunächst deaktiviert werden, auch wenn sie noch nicht verknüpft sind. Das reduziert aber das Risiko, dass sie versehentlich zu früh aktiviert werden und zu unerwünschten Änderungen führen. Die Deaktivierung muss jeweils manuell über den Befehl Status der Gruppenrichtlinie/Alle Einstellungen deaktiviert erfolgen (Bild 7). Dort hat man auch die Möglichkeit, die Einstellungen nur für Benutzer oder Computer zu deaktivieren, was später wichtig wird, wenn Richtlinien nur für Computer – beispielsweise bei Servern – oder Benutzer gelten sollen.

Alle diese GPOs gelten zunächst für die spezielle Gruppe Authentifizierte Benutzer. Diese Einstellung muss gegebenenfalls noch angepasst werden – allerdings nur insoweit, als GPOs beispielsweise auf der Domänenebene zugeordnet werden, wie es bei einer Richtlinie Benutzer mit erhöhten Berechtigungen für die „Low-End-Operatoren“ im Fachbereich der Fall wäre.

Richtlinien bearbeiten und verknüpfen

Im folgenden Schritt können die Richtlinien nun bearbeitet werden. Wie bereits weiter oben ausgeführt, sollte man nicht versuchen, alle Änderungen beispielsweise für die Standardrichtlinie in eine GPO zu packen, sondern gegebenenfalls mit mehreren Richtlinien arbeiten. Im Beispiel gibt es die Internet Explorer-Richtlinie und die Desktopeinstellungs-Richtlinie.

Nachdem die Richtlinien vorbereitet wurden, müssen sie den OUs zugeordnet werden. Das kann natürlich schrittweise erfolgen, indem man Richtlinien für verschiedene spezielle Bereiche wie Server oder für verschiedene Themenfelder wie die Internet Explorer-Konfiguration nach und nach entwickelt und aktiviert.

Nach der Bearbeitung der Richtlinieneinstellungen müssen die GPOs mit den Container verknüpft werden, bei denen sie angewendet werden sollen. Die Server-Standardrichtlinie wird beispielsweise mit dem Container Server verknüpft. Dazu kann man in der GPMC einfach Drag&Drop anwenden. Beim Ablegen des GPOs auf der OU Server wird ein Dialogfeld angezeigt, in dem die Verknüpfung bestätigt werden muss (Bild 8).

Bei einem Container wie Server ist zu überlegen, ob alle Einstellungen dort gesetzt werden oder ob nur die Parameter aus übergeordneten Richtlinien überschrieben werden sollen. Die Vererbung kann über den Befehl Vererbung deaktivieren aus dem Kontextmenü deaktiviert werden. Danach wird bei der OU ein weißes Ausrufezeichen auf blauem Grund angezeigt, so dass sofort sichtbar ist, dass die Vererbung deaktiviert wurde. Außerdem werden nur noch die direkt zugeordneten GPOs angezeigt, aber keine der übergeordneten Ebene. Die Bilder 9 und 10 zeigen die Informationen aus dem Register Gruppenrichtlinienvererbung bei deaktivierter und aktivierter Vererbung.

Nachdem dem Container die Richtlinie Server-Standardrichtlinie zugeordnet wurde, wird im folgenden Schritt die Richtlinie Mailserver-Richtlinie dem Container Mail-Server zugewiesen. Einstellungen in der Mailserver-Richtlinie überschreiben damit die allgemeinen Festlegungen für Server.

In den meisten Fällen wird man pro OU eine GPO zuordnen. Die Priorität wird durch die Standardvererebungsregeln gesteuert. Ausnahmen bestätigen aber auch hier die Regel. Besonders deutlich wird das auf der Ebene der Domäne. Dort müssen auch im Beispiel mehrere GPOs zugeordnet werden. Sobald man mit mehr als einer GPO bei einem Container arbeitet, muss die Priorität gesteuert werden.

Standardmäßig hat die Default Domain Policy die höchste Priorität. Wird diese aber nur als Fallback verwendet für den Fall, dass andere Richtlinien deaktiviert wurden, sollte sie die niedrigste Priorität erhalten oder ganz deaktiviert werden. Eine eigene Standard-Domänenrichtlinie sollte ebenfalls eine niedrige Priorität haben, weil die Festlegungen in dieser Richtlinie von speziellen Festlegungen anderer GPOs überschrieben werden können. Entsprechend folgen in aufsteigender Priorität spezielle Richtlinien für einzelne Konfigurationsbereiche. Deren Reihenfolge ist unerheblich, solange die GPOs überschneidungsfrei konzipiert sind. Die höchste Priorität erhalten schließlich Richtlinien für spezielle Benutzergruppen, die diesen höhere Berechtigungen geben (Bild 11). Im Beispiel ist das die Richtlinie Benutzer mit erhöhten Berechtigungen, bei der allerdings auch eine Sicherheitsfilterung genutzt werden muss.

An diesen Schritten wird aber deutlich, dass man selbst bei einer etwas größeren Zahl von Richtlinien und OUs recht gut den Überblick behalten kann, weil man in einem so klaren Konzept genau weiß, was in welcher Richtlinie konfiguriert ist.

Zu guter Letzt sollte man nicht vergessen, die Richtlinien auch zu aktivieren. Erst dann wirken sich die Änderungen auch bei der nächsten Aktualisierung auf das Systemverhalten aus – in der Regel also beim Start eines Rechners und bei der Authentifizierung durch einen Benutzer.

Sichern und Importieren

Die bisherigen Ausführungen haben sich auf die Nutzung von Richtlinien innerhalb einer Domäne bezogen. In vielen Fällen sind Richtlinien aber auch über Domänengrenzen hinweg identisch, beispielsweise bei den Festlegungen zum Internet Explorer oder oftmals auch bei den Standardrichtlinien für Desktops.

Um nun die gleichen GPOs nicht mehrfach erstellen und pflegen zu müssen, könnte mit Verknüpfungen über die Domänengrenze hinweg gearbeitet werden. Davon ist aber, wie bereits ausgeführt, in der Praxis abzuraten. Die Alternative ist folgende Vorgehensweise:

• Ein spezielles, deaktiviertes GPO wird in der Forest-Root-Domäne erstellt. Dieses GPO wird nirgends verknüpft, sondern dient nur als Basisobjekt, das an anderer Stelle über den Import genutzt wird – also eine Art Vorlage.

• Die Einstellungen in dieser Richtlinie werden bearbeitet.

• Das GPO wird gesichert.

• Es wird in ein GPO in einer anderen Domäne importiert.

Bei Änderungen sind nur noch eine erneute Sicherung und der nachfolgende Import erforderlich.

Die Sicherung eines GPOs erfolgt über den Befehl Sichern im Kontextmenü. Im angezeigten Dialogfeld müssen das Verzeichnis für die Speicherung und eine Beschreibung angegeben werden (Bild 12).

Der nächste Schritt ist der Import, der immer nur in ein bereits vorhandenes GPO erfolgen kann. Dieses muss zunächst in den verschiedenen Domänen erstellt werden.

Ein Assistent leitet durch den Importprozess. Er empfiehlt zunächst eine Sicherung des aktuellen GPOs. Das sollte gemacht werden, wenn es sich nicht um ein neu erstelltes, sondern um ein bereits bestehendes GPO handelt, das durch den Import aktualisiert werden soll.

Im nächsten Schritt können der Sicherungsordner und die zu importierende Richtlinie ausgewählt werden (Bild 13). Standardmäßig werden hier – soweit vorhanden – mehrere Versionen von Richtlinien gewählt. Außerdem kann mit Einstellungen anzeigen auch auf die detaillierten Festlegungen zu den Einstellungen in einer Gruppenrichtlinie zugegriffen werden, wobei in diesem Fall die HTML-Ansicht verwendet wird, die auch in der GPMC genutzt wird. Das ist gegebenenfalls hilfreich, um noch einmal zu verifizieren, ob es sich um die richtige GPO-Version handelt.

Dann werden die Sicherheitsprinzipale und UNC-Pfade überprüft und gegebenenfalls angepasst. Sicherheitsprinzipale können beispielsweise Gruppennamen sein, während UNC-Pfade auf Server verweisen. Bei der Übernahme einer GPO in eine andere Domäne sind zwangsläufig Anpassungen erforderlich. In Fällen, in denen sehr viele solcher Anpassungen nötig werden, empfiehlt es sich, diese Teile der Richtlinie direkt in jeder Domäne zu definieren, auch wenn das einen höheren Erstellungs- und Pflegeaufwand bedeutet. Der Vorteil ist die größere Übersichtlichkeit. Wenn es dagegen nur um wenige Anpassungen geht, lässt sich das beim Import gut beherrschen.

Damit sind alle Informationen für den Import vorhanden. Dieser kann nun durchgeführt werden, und die Richtlinie, in die der Import erfolgt, ist auf dem gleichen Stand wie die Vorlage. Noch schöner wäre es, wenn Microsoft solche Vorlagen standardmäßig unterstützen würde. Vielleicht kommt das ja in einem zukünftigen Release.

Sicherungs- und Importfunktionen können auch genutzt werden, um nur eine Standardrichtlinie für Domänen zu nutzen, in die spezielle Änderungen aus Teilrichtlinien wie denen für den Internet Explorer und die Desktopkonfiguration importiert werden. Damit werden auf Domänenebene weniger Richtlinien zugeordnet, und die Clients müssen weniger Richtlinien verarbeiten. Der Ansatz ist aber insgesamt deutlich unübersichtlicher als die in diesem Artikel vorgestellte Vorgehensweise, und Übersichtlichkeit ist so ziemlich das Wichtigste bei der Nutzung von Gruppenrichtlinien.