Freitag, 3. Februar 2012

CSEs die ohne Richtlinienänderung Einstellungen erneut setzen

Wie im vergangenen Post bereits angekündigt, werden Richtlinien unter gewissen Umständen auch ohne Änderung der Versionsnummer der Group Policy erneut angewendet.

Das Verhalten der Client Side Extensions wird jedoch auch durch einen Registrykey beeinflusst. Dieser Key nennt sich "NoGPOListChanges" und ist zu finden unter:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\GUID\

Existiert dieser Key nicht oder er ist auf 0x1 gesetzt,
werden die Einstellungen dieser CSE auch ohne Versionsänderungen erneut angewendet.

Ich habe mir einmal die Mühe gemacht, eine Liste zu erstellen, mit dem Standardverhalten der folgenden CSEs:

Nameohne Änderung angewendet
Audit Policy Configuration Ja
Deployed Printer Connections Ja
Enterprise QoS Ja
Folder Redirection Ja
Group Policy Applications Ja
Group Policy Data Sources Ja
Group Policy Device Settings Ja
Group Policy Drive Maps Ja
Group Policy Environment Ja
Group Policy Files Ja
Group Policy Folder Options Ja
Group Policy Folders Ja
Group Policy Ini Files Ja
Group Policy Internet Settings Ja
Group Policy Local Users and Groups Ja
Group Policy Network Options Ja
Group Policy Network Shares Ja
Group Policy Power Options Ja
Group Policy Printers Ja
Group Policy Regional Options Ja
Group Policy Registry Ja
Group Policy Scheduled Tasks Ja
Group Policy Services Ja
Group Policy Shortcuts Ja
Group Policy Start Menu Settings Ja
IP Security Ja
Microsoft Offline Files Ja
Software Installation Ja
802.3 Group Policy Nein
CP Nein
Internet Explorer Branding Nein
Internet Explorer Machine Accelerators Nein
Internet Explorer User Accelerators Nein
Internet Explorer Zonemapping Nein
Microsoft Disk Quota Nein
QoS Packet Scheduler Nein
Registry Nein
Remote Desktop USB Redirection Nein
Scripts Nein
Security Nein
TCPIP Nein
Windows Search Group Policy Extension Nein
Wireless Group Policy Nein


Die vollständige Liste incl. GUIDs der CSEs findet ihr hier:

https://skydrive.live.com/redir.aspx?cid=62a6d19ffda7f555&resid=62A6D19FFDA7F555!112&parid=62A6D19FFDA7F555!110

Nun muss nur noch definiert werden, was man hier unter "angewendet" versteht. Einige CSEs wie z.B. "Software Installation", "Folder Redirection" können bekanntlich nur im Vordergrund ausgeführt werden.

Wenn man also von "die Policy wurde erneut angewandt" spricht, so ist das nicht ganz korrekt. Die Einstellungen der CSE "Software Installation" werden also beim Background-Refresh erneut gezogen, die eigentliche Anwendung der Policy kann jedoch nur im Vordergrund erfolgen, d.h. beim nächsten Startup oder Logon.


Montag, 30. Januar 2012

The lies of GPOs! #5

#5

"Nur geänderte Gruppenrichtlinien werden erneut angewendet"

Jede Richtlinie speichert die aktuelle Version der Richtlinie an zwei Stellen.
Einmal im Active Directory und einmal in der gpt.ini.


Die gpt.ini liegt im Sysvol des Active Directory unter \\domain.intern\sysvol\domain.intern\Policies\{GUID}.

Es wird sowohl die Version der User- als auch Computerpolicy gespeichert.
Wie der gespeicherte Wert berechnet wird, lässt sich hier nachlesen:

http://blogs.technet.com/b/grouppolicy/archive/2007/12/14/understanding-the-gpo-version-number.aspx

Die allgemein verbreitete Meinung:
Policies werden nur dann erneut angewendet, wenn sich die Versionsnummer ändert.

Testumgebung:

OK, schauen wir uns das in einer Testumgebung einmal an.



In diesem Beispiel wurden drei GPOs angelegt.
In den Richtlinien wurde als Beispiel das Logging für GPOs aktiviert.

Beispiel gpo1:

In gpo2 wurde das Logging für "Datenquellenrichtlinien-Verarbeitung" aktiviert.
In gpo3 wurde das Logging für "Geräterichtlinienverarbeitung" aktiviert.

Wurden die Richtlinien bereits angewandt und wir führen ein "gpupdate" aus,
werden die Richtlinien nicht erneut angewendet.

Dies wird im gpsvc.log vermerkt:
GPSVC(3f0.1850) 12:46:19:400 ProcessGPOs: Processing extension Registrierung
GPSVC(3f0.1850) 12:46:19:400 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3f0.1850) 12:46:19:400 CompareGPOLists:  The lists are the same.
GPSVC(3f0.1850) 12:46:19:400 CheckGPOs:
No GPO changes and no security group membership change and extension Registrierung has NoGPOChanges set.


Änderung an gpo1:

Wenn wir nun also gpo1 ändern, so sollte diese erneut angewendet werden.
Die Richtlinien gpo2 und gpo3 jedoch nicht.

Um es zunächst ohne Logfile zu überprüfen, ändere ich manuell mittels regedit alle Werte ab, die von den Policies gesetzt werden.

Per Policy werden diese Werte gesetzt:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
    LogLevel    REG_DWORD    0x2 von gpo1

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
    LogLevel    REG_DWORD    0x2 von gpo2

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
    LogLevel    REG_DWORD    0x2 von gpo3


Diese Werte ändere ich manuell per regedit auf:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x3

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x3

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3


Wenn nun nur gpo1 erneut angewendet wird, sollte das Ergebnis wie folgt aussehen:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD
0x2 durch die änderte gpo1 gesetzt
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD
0x3 gleichbleibend, da gpo2 nicht verändert wurde
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x3 gleichbleibend, da gpo3 nicht verändert wurde


Das Ergebnis ist jedoch:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{1A6364EB-776B-4120-ADE1-B63A406A76B5}
LogLevel REG_DWORD 0x2
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{728EE579-943C-4519-9EF7-AB56765798ED}
LogLevel REG_DWORD 0x2

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Group Policy\{F9C77450-3A41-477e-9310-9ACD617BD9E3}
LogLevel REG_DWORD 0x2


D.h. es werden alle Policies erneut angewendet, obwohl nur Policy "gpo1" geändert wurde.

Zu erkennen ist das auch im gpsvc.log:
GPSVC(3b0.444) 15:58:28:765 ProcessGPOs: Processing extension Registrierung
GPSVC(3b0.444) 15:58:28:765 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3b0.444) 15:58:28:765 CompareGPOLists:  Different version numbers found


...

GPSVC(3b0.444) 15:58:28:859 ParseRegistryFile: Entering with <\\domain.intern\sysvol\domain.intern\Policies\{A52DB6EF-C428-4FA6-AC0E-C614891A9CC1}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:859 SetRegistryValue: LogLevel => 2  [OK]
...

<\\domain.intern\sysvol\domain.intern\Policies\{A8CD3DB6-5A58-4437-82EB-DDD14A062AA6}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:875 SetRegistryValue: LogLevel => 2  [OK]
...

<\\domain.intern\SysVol\domain.intern\Policies\{4F685E24-6F86-4088-B45C-E9BA66B06B6C}\Machine\registry.pol>.
GPSVC(3b0.444) 15:58:28:906 SetRegistryValue: LogLevel => 2  [OK]
...


Fazit:

In diesem Beispiel wurden also auch Policies angewandt, deren Versionsnummer sich nicht geändert hat (gpo2 und gpo3).

Das Geheimnis - Ändert sich eine GPO innerhalb einer CSE (Client Side Extension), so werden alle Policies, welche Einstellungen dieser CSE besitzen, erneut angewendet.

Habe ich also zum Beispiel 100 GPOs verlinkt, die Einstellungen innerhalb der "Administrative Vorlagen" beinhalten und ich ändere nur eine GPO von diesen, so werden die "Administrativen Vorlagen" von allen 100 Policies erneut angewendet!

Zusätzlich zu diesem Verhalten, lässt sich pro CSE einstellen, ob Einstellungen auch ohne Änderungen übernommen werden sollen.
Dieses Thema werde ich jedoch erst im nächsten Post behandeln.



Sonntag, 8. Januar 2012

The IP Address is not a valid DNS address ...

Diesmal ein Phänomen aus dem Bereich DHCP/DNS.
Beim Hinzufügen eines DNS Servers in den Bereichsoptionen des DHCP Servers erscheint folgende Fehlermeldung:

"The IP Address x.x.x.x is not a valid DNS address, do you still want to add it ?"





Bei dieser Fehlermeldung kommen einem erst einmal folgende Gedanken in den Sinn:

  • Wurde eine falsche IP-Adresse angegeben?
  • Ist der DNS Server vom DHCP Server aus erreichbar?
  • Lassen sich Adressen per nslookup auflösen?
  • Liegt eine Fehlkonfiguration am DNS Server vor?
  • Blockiert eine Firewall ggf. den Netzwerkverkehr?
Nachdem alle diese Fragen geklärt sind und der Server aber sich dennoch nicht ohne Fehlermeldung hinzufügen lässt, stellt sich letztendlich noch die Frage:
  • Wie ermittelt der DHCP Server ob es sich um einen gültigen DNS Server handelt? 
Gute Frage. Innerhalb der Technet-Pages finden sich keine relevanten Informationen. Auch sonst nur wenige Suchergebnisse die sich mit diesem Thema befassen.

Deshalb, schauen wir doch einmal was hier passiert.
Dazu hier ein Mitschnitt mittels WireShark:




Nach einer kurzen Analyse lässt sich feststellen, es wird folgende Abfrage ausgeführt: "Standard Query SOA".
Vermeintlich wird also der "Start of Authority" Eintrag abgefragt.
Ok, vielleicht fehlt dieser DNS Eintrag auf dem betreffenden Server.
Dies lässt sich per DNS SnapIn ermitteln oder per nslookup:

nslookup -type=soa domain.local dnsserver.domain.local

Auch das scheint nicht der Fehler zu sein.
Der SOA Record ist vorhanden.
Fehlen ggf. noch andere DNS Einträge?
Die benötigten DNS-Records für das Active Directory lassen sich mittels
dnslint /ad prüfen:

http://support.microsoft.com/kb/321045/de

Auch hier, soweit keine Fehler ersichtlich.
Ok, nun also noch einmal ein Blick auf den WireShark Mitschnitt.

Recursion desired: Do query recursively.
Recursion available: Server can do recursive queries.


In einigen Mitschnitten erscheint auch:

Recursion available: Server can't do recursive queries.


Es scheint also eine Prüfung stattzufinden, ob der angegebene DNS Server
"recursion queries" durchführen kann.


Als "recursion query" bezeichnet man den Vorgang, wenn ein Client Anfragen an den DNS Server stellt, dieser die Anfragen aber nicht beantworten kann und deshalb die Anfragen an einen weiteren DNS Server weiterreicht.
Ok, nun sind wir also wieder einen Schritt weiter.

Üblicherweise werden die recursion queries and die "Root Hints" weitergegeben.
Zumindest dann, wenn keine Forwarder eingerichtet wurden.

Hier die Liste der default Root Hints:



Die recursion lässt sich auch direkt am DNS Server testen:



In diesem Falle schlägt diese, wie erwartet, fehl.
Ein Blick in die Firewall des Unternehmens verrät, dass diese Anfrage dort geblockt wird. Nachdem eine Ausnahmeregel definiert wurde, lässt sich der DNS Server ohne Fehler im DHCP Server hinzufügen.
Der recursion test ist ebenfalls erfolgreich.

Fazit:
Beim Hinzufügen eines DNS Servers prüft der DHCP Server (besser gesagt das DHCP Snap-In) ob der DNS Server "recursion queries" ausführen kann.
Hat der DNS Server keine Verbindung zu den Root Hints bzw. die Verbindung ist vorhanden aber die vorhandenen Firewall Richtlinien verhindern die Kommunikation, lässt sich der DNS Server nicht hinzufügen.




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.



Dienstag, 29. November 2011

GPO Loopback benötigt Leserechte für den Computer-Account - oder doch nicht?

*** Update siehe Ende des Artikels ***

Dieses mal einen außerplanmäßigen Post (nicht in der Reihe "The lies of GPOs!").

Einige benutzen den Loopbackmodus.

Im Normalfall wird für den Benutzer, der Benutzeranteil der Richtlinie angewandt, die auf der OU des Users bzw. einer darübergelegenen OU verlinkt ist. Der angewandte Computeranteil wird anhand der Position des Computerobjektes im AD gelesen.

In einigen Situationen ist dies jedoch nicht erwünscht.

Stellen wird uns beispielsweise vor, ein Benutzer meldet sich an einem Terminalserver an. Es wirken also die Computereinstellungen, die durch das Computerobjekt des Terminalservers gelesen werden.
Die Benutzereinstellungen werden allerdings anhand des Benutzerobjektes angewandt. Ein Admin eines Terminalserver möchte jedoch meistens ebenfalls Benutzereinstellungen definieren, die nur für die Anmeldung an dem Terminalserver gelten. Oftmals ist es sogar gewünscht, dass die "normalen" Benutzereinstellungen, also diejenigen die über die Position des Benutzerobjektes gefunden werden, ignoriert werden.

Dieses Verhalten lässt sich mit Loopback beeinflussen.
Das genaue Verfahren möchte ich an dieser Stelle nicht erklären,
eine übersichtliche Auflistung findet sich hier:

http://www.msxfaq.de/verschiedenes/gpo.htm

Ist Loopback aktiv, so reichte es bis einschließlich Windows XP und Server 2003 aus, wenn der User Leserechte und Rechte zum Übernehmen der Policy hatte.

Haben wir z.B. eine OU, in der 5 Terminalserver vorhanden sind und es ist eine GPO mit Usereinstellungen verlinkt, so werden diese Settings für alle Benutzer angewandt, die sich an den Terminalservern anmelden (vorausgesetzt Loopback ist aktiv).

Es besteht also keine direkte Möglichkeit, an dieser Stelle eine Beziehung zum Computeraccount herzustellen.
Möchte ich die Policy nur an 2 von den 5 Terminalservern anwenden, so ist dies nur per WMI-Filter möglich.

Ab Windows Vista wurde deshalb ein zusätzlicher Filtermechanismus eingebaut.
Damit die Benutzereinstellungen mittels Loopback angewandt werden, muss zusätzlich das Computerobjekt mindestens Leserechte auf die Policy haben.
Andernfalls werden die Benutzereinstellungen dieser Policy trotz Loopback nicht angewandt. Zu unserem Beispiel also, wird in der Policy nur Terminalserver1 und Terminalserver2 mit Leserechten eingefügt, so wird diese auch nur an diesen 2 Terminalservern übernommen und nicht an allen 5.

Wie oben im Link beschrieben, gibt es zwei Modi für Loopback.
Merge und Replace.

Nun zum Problem.
Was bisher nirgends dokumentiert ist:

Die neue Sicherheitsfilterung gilt nur für Loopback-Merge.
Nicht für Loopback-Replace.

Der offizielle KB-Artikel ist dieser hier:
http://support.microsoft.com/kb/953768/en-us

Ich habe offiziell eine Korrektur für diesen Artikel eingereicht.
Bisher ist der Artikel allerdings noch auf dem alten Stand.

Unter Loopback-Replace wird dieser neue Mechanismus nicht verwendet.

Update 07.03.2013:
Der Artikel wurde nun aktualisiert und ist deutlich präziser.