Samstag, 31. Dezember 2011

The lies of GPOs! #4

#4

"WMI Filter sind nicht performant"

Eine Aussage, zu der auch ich mich immer wieder hinreißen ließ.
Grundlage dieses Posts ist diese Diskussion aus dem Technet Group Policy Forum:

http://social.technet.microsoft.com/Forums/de-DE/gruppenrichtliniende/thread/0c9107c8-2282-4a1f-b5e5-1c9064709908


Vorneweg, die Aussage ist falsch.
Richtig müsste es lauten "einige WMI Filter sind nicht performant".


Aber zunächst, was ist ein WMI Filter?

Ein WMI Filter ist eine von verschiedenen Möglichkeiten, den Wirkungsbereich einer Gruppenrichtlinie zu beschränken.

Bei einfachen Ausgrenzungen wie einzelnen Computern und Benutzern lässt sich dies auch über eine Sicherheitsfilterung realisieren.

Was ist aber z.B. wenn die Richtlinie nur für alle Windows Server 2008 gelten soll?

In diesem Falle kann z.B. ein WMI Filter benutzt werden.
WMI = Windows Management Instrumentation

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

Der funktionierende Filter für unser Beispiel wäre also:

SELECT * FROM Win32_OperatingSystem WHERE Version LIKE “6.0.%” AND ProductType <> “1”

Dieser Filter kann vorab getestet werden. Z.B. mit diesem PowerShell Befehl:

Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '6.0.%' AND ProductType <> '1'"

Wird dieser Befehl nun beispielsweise auf einem Windows 7 System ausgeführt,
erhält man kein Ergebnis.
Für einen WMI Filter innerhalb einer GPO würde dies bedeuten, der WMI Filter liefert das Ergebnis "false".  Die Policy wird nicht angewendet.


Zeiten messen:

Nun aber zum eigentlichen Problem, die Ausführungszeit eines WMI Filters.
Diese lässt sich ebenfalls mit einem PowerShell Befehl ermitteln:

measure-command {Get-WmiObject -query "SELECT * FROM Win32_OperatingSystem WHERE Version LIKE '6.0.%' AND ProductType <> '1'"} 

Der Output ist wie folgt:

Days              : 0
Hours             : 0
Minutes           : 0
Seconds           : 0
Milliseconds      : 80
Ticks             : 800080
TotalDays         : 9,26018518518518E-07
TotalHours        : 2,22244444444444E-05
TotalMinutes      : 0,00133346666666667
TotalSeconds      : 0,080008
TotalMilliseconds : 80,008


Dieser WMI Filter benötigt also in etwa 80 Millisekunden auf meinem Testgerät.

Weshalb also die Idee, ein WMI Filter könnte die Abarbeitung der Gruppenrichtlinien deutlich verlangsamen?

Die Aussage selbst stammt direkt von Microsoft:

"WMI filters can take significant time to evaluate, so they can slow down logon and startup time. The amount of time depends on the construction of the query."


"...  Also, there is no time-out for WMI filters. Use them only when necessary."

http://technet.microsoft.com/de-de/library/cc758471(WS.10).aspx

Diese Aussage ist allerdings nun schon einige Jahre alt und trifft auf moderne Systeme die mit Multi-Cores arbeiten nur noch bedingt zu.

Die Testumgebung:

Um reale Daten zu liefern, hat MVP Mark Heitbrink folgende Testumgebung benutzt (vielen Dank noch einmal an dieser Stelle):

  • 200 GPOs
  • 200 WMI Filter
  • "select * from Win32_IP4RouteTable where Name like '192.168.22.%'"

Ergebnis:

Übernahme GPO Prozess mit 5 "Standard" GPOs: 0,6 - 0,7 Sekunden
Übernahme GPO Prozess mit 200 WMI GPOs: 4,3 - 4,7 Sekunden

Also eine Differenz von 3,5 - 4 Sekunden, also nahezu nichts.


langsamer Filter:

Welcher Filter kann also z.B. ein System ausbremsen?
Nehmen wir doch einmal diesen Filter:


measure-command {Get-WmiObject -query "Select * from Win32_Product where Name like '%Adobe Reader%'"}

Die Ausführung dauert auf meinem Testsystem 66 Sekunden.
(wohl gemerkt bei einem Intel Core i5)

Die schlechte Performance der Win32_Product Klasse ist bekannt.
In diesem Beispiel soll der Filter nach dem "Adobe Reader" suchen.
Ist dieser installiert, wird ein "true" zurückgegeben.

Damit die Abfrage Daten liefern kann, muss diese jedoch intern den MSI Provider benutzen. Dadurch wird ein Konsistenzcheck über alle installierten MSI Pakete ausgelöst, welcher eine Neukonfiguration und Reparaturinstallation aller Pakete startet. Je nach Anzahl der installierten MSI Pakete kann dies viel Zeit in Anspruch nehmen.

Dokumentiert ist dieses Verhalten unter diesem KB Artikel:
http://support.microsoft.com/kb/974524

Dieser Filter ist nur ein Beispiel, ein anderes wäre z.B. der WMI Provider für Active Directory. Dieser kann je nach Query ebenfalls längere Zeit in Anspruch nehmen.


Timeout?

Nun stellt sich also die Frage, gibt es einen Timeout bei der Abfrage von WMI Filtern (einer GPO)?
Gut, das hatten wir bereits geklärt oder?

"... Also, there is no time-out for WMI filters. Use them only when necessary."

Dies trifft aber ab Windows 6.0 SP2 und Windows 6.1 SP1 nicht mehr zu.
Hier wurde ein weiterer WMI Provider für GPO WMI Filter eingeführt, der alle WMI Abfragen die länger als 30s dauern mit "false" beantwortet.

Erkennbar ist dies im gpsvc.log:

GPSVC(424.49c) 12:34:17:615 ProcessGPO: Searching <cn={A865D64C-77CF-4BE5-B600-5712D1C932F9},cn=policies,cn=system,***>
GPSVC(424.49c) 12:34:17:615 ProcessGPO: Machine has access to this GPO.
GPSVC(424.49c) 12:34:17:615 FilterCheck: Found WMI Filter id of: <[***;{C7920CE4-D605-4A2E-9F1F-A3401000132E};0]>
GPSVC(424.49c) 12:34:47:585 FilterCheck: Evaluate returned error. hr=0x80041069


Leider konnte ich bisher keine offizielle Doku zu diesem Verhalten finden.
Ein weiterer Grund, den WMI Filter vorher zu messen und sorgsam auszuwählen.

Fazit:

WMI Filter sind nicht per se unperformant.
Es kommt auf den jeweiligen Filter an.

Als grober Anhaltspunkt kann der Filter vorher mittels dem PowerShell Befehl measure-command gemessen werden.

Tipp:

Die genauen Laufzeiten der WMI Filter sind im gpsvc.log erkennbar.
Das Logging kann per Registry aktiviert werden:

http://blogs.technet.com/b/deds/archive/2010/01/12/group-policy-debug-logging-gpsvc-log-in-windows-7-und-server-2008-r2.aspx


Um das Logfile vernünftig mit dem Policy Reporter von SysPro auszuwerten:
http://www.sysprosoft.com/policyreporter.shtml


Mittwoch, 28. Dezember 2011

The lies of GPOs! #3

# 3

"Gruppenrichtlinien wirken auf Gruppen"

Diesmal ein Mythos aus der Kategorie Basics, der jedoch immer wieder
anzutreffen ist.

In den Einstellungen einer GPO besteht die Möglichkeit eine Sicherheitsfilterung einzustellen.




An dieser Stelle können einzelne Benutzer, Gruppen und Computerkonten eingetragen werden. Der Name Gruppenrichtlinie lässt vermuten, dass diese
über Gruppen angewandt werden.
Einige Admins tragen an dieser Stelle die gewünschte Gruppe von Usern ein, für die die Policy gelten soll. Dies reicht jedoch noch nicht aus um eine Policy anzuwenden. Policies werden erst dann angewandt, wenn diese "verlinkt" sind.


Würde man also beispielsweise die Gruppe "Einkauf" in der Sicherheitsfilterung hinzufügen und die Policy nicht mit einer Organisationseinheit verlinken, hätte dies keine Auswirkung. Die GPO wird nicht angewandt.

Wird die Richtlinie jedoch mit einer Organisationseinheit oder ganz oben auf der Domäne verlinkt, so wird diese angewandt.

Die Sicherheitsfilterung kann die Anwendung der GPO beschränken, Richtlinien werden jedoch nicht auf Gruppen angewandt!

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" angewandt 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 also 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.

Natürlich gibt es auch hier, wie überall, Ausnahmen.
Diese werden allerdings an dieser Stelle nicht behandelt.

Enhält eine Policy beides, also User- und Computereinstellungen, muss diese
in unserem Beispiel wie folgt verlinkt werden:

└───domain.intern
├───germany --- Test-GPO-USR-COM
│ ├───com
│ └───usr
└───usa
├───com
└───usr


Zurück also zum Beispiel mit der Sicherheitsgruppenfilterung der Gruppe "Einkauf". Sollten in diesem Fall also nur die User der Gruppe Einkauf die Policy erhalten?
Nein. Standardmäßig ist folgende Gruppe in der Sicherheitsfilterung vorhanden:

Authentifizierte Benutzer:
Lesen
Gruppenrichtlinie übernehmen

Diese Gruppe beinhaltet alle Computer- und Benutzerkonten im AD.
Soll also anhand der Gruppe "Einkauf" gefiltert werden, muss der
Gruppe "Authentifizierte Benutzer" das Recht genommen werden, die Policy zu übernehmen.


Bedacht werden sollte allerdings, dass dies auch bedeutet, dass ebenfalls (falls vorhanden) die Computereinstellungen nicht mehr angewandt werden.

Alle Computer die den Anteil der Computereinstellungen übernehmen sollen, müssen also dazu berechtigt werden die Policy zu übernehmen.
Dies kann ebenfalls einzeln geschehen, in dem die Computerkonten in den ACLs der Sicherheitsfilterung eingetragen werden oder durch eine Gruppe, die die betreffenden Computerkonten beinhaltet.

Näheres zum Thema Sicherheitsfilterung findet ihr bei MVP Mark Heitbrink:

http://www.gruppenrichtlinien.de/index.html?/HowTo/Richtlinien_pro_Benutzer_einrichten.htm

Der Mythos Gruppenrichtlinien wirken auf Gruppen ist also falsch.

Gruppenrichtlinien wirken immer auf
Computer- bzw. Benutzerkonten.


Sonntag, 11. Dezember 2011

Procmon als Dauerläufer?

Einigen sollte "Process Monitor" ein bekannter Begriff sein.
Der Procmon ist ein äußerst hilfreiches Tool von Sysinternals.

http://technet.microsoft.com/de-de/sysinternals/bb896645


Vor einigen Jahren wurden der ehemalige Filemon (zeichnete Filezugriffe auf) und Regmon (Pendant für Registryzugriffe) miteinander verschmolzen und zusätzlich um einige Funktionen erweitert.
Herausgekommen ist dabei ein geniales Tool, der Process Monitor.


Dieses Programm eignet sich um aktuelle Zugriffe mitzuschneiden.
Was viele nicht wissen, es ist mindestens genauso brauchbar um ein längerfristiges Logging zu aktivieren.


Als Beispiel nehme ich einmal einen "Klassiker", die Frage:

Wer löscht Dateien aus meinem Verzeichnis?

Eine Möglichkeit der Überwachung ist natürlich die Überwachungsrichtlinie.
Auf NTFS Ebene können in den SACLs (System Access Control Lists) Überwachungseinträge angelegt werden.
Setzen wir also einen Überwachungseintrag auf "Unterordner und Dateien löschen", so wird beim Löschen in den betreffenden Verzeichnissen/Dateien ein Eintrag im Eventlog erzeugt. Leider ist das Ganze im Security Eventlog des

betreffenden Servers/Clients auf dem die Daten liegen sehr unübersichtlich.

Damit überhaupt überwacht wird, muss zunächst folgende Policy aktiviert werden:

Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Lokale Richtlinien\Überwachungsrichtlinie\Objektzugriffsversuche überwachen

Was nun aber, wenn ich die gesammelten Logs filtern möchte und ggf. auch archivieren möchte / muss?

Der Process Monitor bietet von Haus aus eine Fülle von Möglichkeiten Daten zu filtern. Sollen nicht nur Filezugriffe geloggt werden, sondern auch Registryzugriffe, so ist der Procmon die bessere Wahl.

Fallen hier nicht zu viele Daten an?

Ja.
Per Default loggt der Process Monitor alle Registry-, Filezugriffe mit.
(um es genau zu sagen, sogar noch etwas mehr, welches aber für diesen Anwendungsfall nicht relevant ist).

Setzt man im Vorfeld die betreffenden Filter, so wird trotzdem alles geloggt.
Das kann Vorteile haben (wenn man zum Beispiel im Nachhinein einen anderen Filter benötigt als ursprünglich vermutet), in der Regel möchte man jedoch nur die definierten Daten aufheben.

Hierfür stellt der Procmon folgende Option bereit:




"Drop Filtered Events" verwirft alle Events, die nicht dem Filter entsprechen.

Wo werden die Logs gespeichert?

Standardmäßig im Pagefile.
Nun ist dies für ein längeres Logging natürlich nicht wirklich sinnvoll.

Die Events können jedoch auch in ein File umgeleitet werden
(unter File > Backing Files ...):




Mit diesem Hintergrundwissen kann es auch schon fast losgehen.
Als Beispiel möchte ich nun alle Löschungen im Verzeichnis C:\myshare
loggen. Als erstes muss ich Filter und Settings definieren.

Dazu wie folgt vorgehen:

1. Process Monitor starten
2. Nur "File System Activity" aktivieren








3. Im Menü Filter > Filter ... wählen
4. "Operation is SetRenameInformationFile" wählen
5. "Path contains C:\myshare" wählen
6. Nun unter Filter > Drop Filtered Events noch aktivieren
7. Diese Settings nun exportieren, File > Export Configuration...

Jetzt kann der Process Monitor mittels Config-File gestartet werden.
Zur Vereinfachung sind in diesem Beispiel alle Files direkt auf C:\ abgelegt:

C:\Procmon.exe /BackingFile C:\mylog /LoadConfig C:\myconfig.pmc /Quiet /Minimized

Nun ist das Logging aktiviert.
In Kombination mit etwas Scripting, kann dies auch zeitgesteuert geschehen (z.B. mittels Aufgabenplanung).

Ein mögliches Beispiel wäre:

C:\Procmon.exe /Terminate
C:\Procmon.exe /BackingFile C:\%date%%random% /LoadConfig C:\myconfig.pmc /Quiet /Minimized

Die entstandenen Logfiles können nun von jedem Client aus geöffnet werden.
Zu beachten ist jedoch, wurde das Logfile auf einem x64 OS erstellt,
so ist auch zum Öffnen des Logs ein x64 System erforderlich.

Der Prozess Monitor muss mit administrativen Berechtigungen gestartet werden.