Im ersten Teil der Reihe "Der große Group Policy Troubleshooting Guide"
geht es um Fehler, die eigentlich keine sind. Man könnte diese Fehler als "Denkfehler" bezeichnen.
Damit Richtlinien überhaupt angewendet werden können, muss der Client diese sehen und darauf zugreifen können.
Scope of Management
Microsoft bezeichnet den Verwaltungs- / Wirkungsbereich von Richtlinen SOM = Scope of Management.
Im SOM der Policy finden sich alle Clients / Benutzer die die Policy anwenden können.
Nehmen wir zum Beispiel eine Policy "GPO-01", die User Settings enthält.
└───Users
└───Sales-01
└───Sales-02 -- GPO-01
Ist die Policy auf der OU "Sales-02" verlinkt, so ist der SOM der Policy
die OU "Sales-02". Im Wirkungsbereich der Policy befinden sich alle
User in dieser OU. User von "Sales-01" befinden sich also nicht im SOM der GPO-01.
Wäre die Richtlinie allerdings an oberster Stelle auf der Domänenebene verlinkt, so umfasst der SOM die gesamte Domäne.
Richtlinien lassen sich auf verschiedenen Ebenen verknüpfen:
- Auf Organisationseinheiten
Benutzer und Computer die sich nicht im Wirkungsbereich einer Policy befinden, können diese auch nicht anwenden.
Benutzer- und Computereinstellungen - Policies richtig verknüpfen
Jede Richtlinie ist in Computer- und Benutzereinstellungen aufgeteilt.
Beinhaltet eine Richtlinie
beispielsweise Benutzereinstellungen, so muss diese auch mit einer OU
verknüpft werden, die User enthält.
Einfaches Beispiel: Wir haben eine "Test-GPO-USR" die ausschließlich
Benutzereinstellungen enthält. Die Active Directory Struktur schaut wie
folgt aus:
└───domain.intern
├───germany
│ ├───com
│ └───usr
└───usa
├───com
└───usr
Die Policy soll nun für alle Benutzer der OU "germany" angewendet werden.
Dies wird erreicht, indem die Policy wie folgt verlinkt wird:
└───domain.intern
├───germany
│ ├───com
│ └───usr ---- Test-GPO-USR
└───usa
├───com
└───usr
Wird die Policy fälschlicherweise wie folgt verlinkt, hat diese keine Auswirkung:
└───domain.intern
├───germany
│ ├───com --- Test-GPO-USR
│ └───usr
└───usa
├───com
└───usr
Die Policy muss immer anhand ihrer Einstellungen verlinkt werden.
Enhält sie nur Computereinstellungen:
Mit einer OU, die Computerkonten enthält.
Enhält sie nur Benutzereinstellungen:
Mit einer OU, die Benutzerkonten enthält.
Merken. Merken. Merken.
Versteht man diese Logik nicht, wird man definitiv auf Probleme bei der Anwendung von Richtlinien stoßen.
Mehr zu diesem Thema in meinem vergangenen Artikel:
http://matthiaswolf.blogspot.de/2011/12/lies-of-gpo-3.html
Loopback Processing:
Loopback Processing ist eine Einstellung, die das Verhalten der GPSVC-Engine verändert. Diese Einstellung gilt immer für alle Richtlinien die ein Computer anwendet.
Die Anwendung der Computereinstellungen werden nicht beeinflusst.
Nur die Benutzereinstellungen werden anders angewendet.
Es gibt zwei Varianten von Loopback.
Loopback Merge:
Hierbei entstehen zwei GPO Durchläufe.
Der erste Durchlauf läuft wie gewohnt ab, die Benutzereinstellungen werden anhand der Position des Benutzerobjekts im Active Directory abgearbeitet.
Ist dieser Prozess abgeschlossen, wird der Suchfilter geändert.
Nun startet ein zweiter Durchlauf, hierbei ist allerdings die Position des Computerobjekts im Active Directory entscheidend.
Zum Verständnis noch einmal, es geht nur um die Anwendung der Benutzereinstellungen.
Loopback Merge verdoppelt die Abarbeitungszeit der Richtlinien nahezu.
Loopback Replace:
Bei Replace ist nur noch die Position des Computerobjekts entscheidend. Es gibt nur einen Durchlauf
.
Loopback ist ein komplexes Thema.
Deshalb noch ein paar Hintergrundinformationen:
http://evilgpo.blogspot.de/2012/02/loopback-demystified.html
http://www.msxfaq.de/verschiedenes/gpo.htm
Wichtig, ab Windows Vista müssen die Sicherheitseinstellung der Richtlinien angepasst werden:
http://matthiaswolf.blogspot.de/2011/11/gpo-loopback-benotigt-leserechte-fur.html
Zur Wiederholung:
Damit Richtlinien überhaupt angewendet werden können, muss der Client diese sehen (Scope of Management) und darauf zugreifen können.
Filtern von Richtlinien / Einschränken des SOM
Innerhalb des Active Directory lässt sich eine gruppenrichtlinienoptimierte Aufteilung realisieren. Allerdings wird es immer wieder Richtlinien und Einstellungen geben, die nur für eine kleinere Benutzer- bzw. Computergruppe gelten sollen. Um dies zu realisieren bieten Gruppenrichtlinien die Möglichkeit den SOM weiter einzuschränken. Es gibt verschiedene Filtermechanismen.
- Sicherheitsfilterungen
- WMI-Filterungen
- Zielgruppenadressierungen (Item Level Targeting)
Sicherheitsfilterungen verstehen
Um diese Filterungsvariante zu verstehen hilft einem ein einfacher Vergleich.
Der Zugriff auf Dateien und Ordner lässt sich mit NTFS Berechtigungen einschränken. So kann zum Beispiel auf Dateiebene eingestellt werden, dass ein Benutzer eine Datei lesen, jedoch nicht bearbeiten kann.
Hierbei gibt es zwei Möglichkeiten.
Es können Berechtigungen zugeteilt oder verweigert werden.
Verweigerungen haben immer Vorrang gegenüber Zuteilungen.
Einfaches Beispiel:
Der Benutzer Peter ist Mitglied der Gruppen "Einkauf" und "Domain Users".
Die Berechtigungseinstellung auf dem Ordner sieht wie folgt aus:
- Domain Users - Lesen erlaubt, Bearbeiten verweigert
- Einkauf - Lesen erlaubt, Bearbeiten erlaubt
Da der Benutzer Mitglied beider Gruppen ist und die Verweigerung Vorrang hat, sieht seine effektive Berechtigung wie folgt aus: Lesen erlaubt.
Dieses Verfahren lässt sich auf die Gruppenrichtlinien übertragen.
Hier gibt es ebenfalls verschiedene Berechtigungsarten.
Die Wichtigste davon ist "Gruppenrichlinie übernehmen".
Diese ist entscheidend für die Anwendung einer Gruppenrichtlinie.
Man kann diese Berechtigungen Benutzer- als auch Computerkonten zuteilen.
Verweigert man einem Computerkonto die Berechtigung "Gruppenrichtline übernehmen" so wird dieser den Anteil "Computereinstellungen" der jeweiligen Richtlinie nicht anwenden können.
Verweigert man einem Benutzerkonto die
Berechtigung "Gruppenrichtline übernehmen" so wird dieser den Anteil
"Benutzereinstellungen" der jeweiligen Richtlinie nicht anwenden können.
Tipp:
Nach Möglichkeit nicht den gesamten Zugriff auf die Policy verweigern.
Dem Benutzer- bzw. Computer sollte das Recht "Lesen" erhalten bleiben um unschöne RSoP (Resultant Set of Policies) Meldungen zu vermeiden.
WMI-Filter verstehen
WMI Filter sind Abfragen die das WMI (Windows Management Instrumentation) Repository benutzen. Mittels WMI lassen sich nahezu alle computerspezifischen Daten abfragen. Da die WMI Filterung noch vor der Unterscheidung von Benutzer- oder Computereinstellungen stattfindet, lassen sich nur nicht-benutzerspezifische Werte abfragen.
mehr Informationen:
http://www.microsoft.com/germany/technet/datenbank/articles/600682.mspx
http://blogs.technet.com/b/askperf/archive/2007/06/12/wmi-architecture-basics.aspx
WMI Filter können zeitintensive Abfragen ausführen.
Schaut euch bitte zu diesem Thema meinen vergangenen Post
The lies of GPOs! #4 - "WMI Filter sind nicht performant" an.
Verkettet man mehrere WMI Filter, so muss man verstehen, dass diese in einer AND Beziehung stehen. Alle Filter müssen den Wert "True" liefern damit die Policy angewendet wird.
Die Kombination aus folgenden Filtern (Abfrage Betriebssystem und Bittigkeit) wird nie den Wert "True" liefern können:
select * from Win32_OperatingSystem WHERE Version < '5000' AND ProductType="1" AND NOT OSArchitecture = "64-bit"
select * from Win32_OperatingSystem WHERE Version > '5000' AND ProductType="1" AND NOT OSArchitecture = "64-bit"
select * from Win32_OperatingSystem WHERE Version > '5000' AND ProductType="1" AND OSArchitecture = "64-bit"
Es kann in diesem Falle immer nur eine Bedingung erfüllt werden.
Würde man also diese drei Filter kombinieren, wäre nur maximal eine Bedingung erfüllt. So würde die Policy nicht angewendet.
Tipp:
Abfragen die länger als 30 Sekunden dauern, werden ab Windows 6.0 SP2 und Windows 6.1 SP1 automatisch mit "False" beantwortet.
Item Level Targeting - jetzt wird es granular
Group Policy Preferences teilen ihre Einstellungen in sogenannten "Elemente / Items" ein. Dies bietet die Möglichkeit viele verschiedene Einstellungen in nur einer Richtlinie darzustellen.
Damit nicht alle Einstellung angewendet werden, lassen sich diese einzelnen Items ebenfalls einschränken. Dazu benutzt man das "Item Level Targeting".
Im ILT gibt es bereits viele vordefinierte Filter.
Diese einzelnen Elemente lassen sich gruppieren und sowohl mit AND als auch mit OR Operatoren verknüpfen.
F5, F6, F7, F8
Eine Besonderheit der Preferences ist wie eben genannt die Granularität.
Mittels der Funktionstasten F5-F8 können einzelne Einstellungen aktiviert / deaktiviert werden.
Vergisst man eine Einstellung zu aktivieren, wird sie nicht am Client angewendet.
Mehr dazu:
http://blogs.technet.com/b/grouppolicy/archive/2008/10/13/red-green-gp-preferences-doesn-t-work-even-though-the-policy-applied-and-after-gpupdate-force.aspx
Weitere Denkfehler
Neben der Missachtung der oben genannten Filtermechanismen und der Beachtung des SOM gibt es noch weitere Logikfehler.
Nachfolgend eine Liste beliebter Denkfehler im Umgang mit GPOs:
- Die Richtlinie wurde versehentlich nicht verknüpft.
Hier sind wir wieder bei dem Punkt "Gruppenrichtlinien sehen". Nur eine richtig verknüpfte Policy kann auch vom Client gefunden und ggf. angewendet werden.
Tipp:
Ob eine Richtlinie überhaupt verknüpft ist, seht ihr am einfachsten im Reiter "Bereich / Scope" :
- Es wurde versehentlich die Benutzer- bzw. Computerkonfiguration der Richtlinie deaktiviert.
Deaktivierte Gruppenrichtlinienteile werden nicht angewendet.
- Die Vererbung der Richtlinien wird falsch verstanden bzw. missachtet. Man muss das Rad nicht neu erfinden, deshalb: http://www.gruppenrichtlinien.de/artikel/vererbung-und-hierarchien/
