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.

Donnerstag, 27. Oktober 2011

The lies of GPOs! #2

# 2
"Die Einstellungen einer GPO werden entfernt, wenn die Policy deaktiviert oder gelöscht wird bzw. der Rechner/User nicht mehr in dem SOM (Scope of Management) der GPO ist."

Ebenfalls ein Trugschluss.

Je nach CSE (Client Side Extension) werden Settings teilweise permanent angewandt.

Typische Beispiele:
  • NTFS oder Registry Berechtigungen
  • Eingeschränkte Gruppen
  • Softwareinstallationen (änderbar)
  • Folder Redirections (änderbar)

Ebenfalls nicht zu verachten, Settings unter Sicherheitseinstellungen>Lokale Richtlinien.

Wurde zuvor hier kein Setting definiert, ist das per GPO angewandte Setting ebenfalls "persistent" also dauerhaft.

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

Das Gleiche gilt für eigene Administrative Vorlagen die ihre Werte außerhalb der Bereiche:

"HKLM\Software\Policies"
"HKLM\Software\Microsoft\Windows\CurrentVersion\Policies"
"HKCU\Software\Policies"
"HKCU\Software\Microsoft\Windows\CurrentVersion\Policies"
schreiben.


Last but not least:

GPP = Group Policy Preferences

Den Meisten nicht bekannt, GPP = Tattooing!
GPPs überschreiben gnadenlos vorhandene Einstellungen.

Beim Entfernen bleiben die Werte, die per GPP definiert wurden, vorhanden.


Deshalb, immer vorher überlegen, welche Werte sollen definiert werden und wie können diese im Zweifelsfalle wieder rückgängig gemacht werden!

Sonntag, 23. Oktober 2011

The lies of GPOs! #1

Joa...

Einer muss es ja machen.
Und zwar, diese Fragen festhalten, die immer wieder zum Thema GPO gestellt werden, aber in dem meisten Fällen falsch verstanden werden!

# 1
"GPO? Nein, nutzen wir nicht!"

Wage ich zu bezweifeln.
Habt ihr ein AD? ... Ja haben wir ...

Dann nutzt ihr auch GPOs! Ihr wisst es nur nicht!

Per Default (oh ja lieben wir nicht alle diese Formulierung? :-) ),
sind im AD zwei Policies vorhanden:

Default Domain Policy = DDP

Default Domain Controllers Policy = DDCP

Ohne diese werdet ihr nicht glücklich!
Allgemein reden wir von Sicherheitseinstellungen,
maximale Gültigkeitsdauer des TGT (Ticket Granting Ticket), maximale Gültigkeitsdauer der ausgestellten Tickets usw.
Auf die einzelnen Settings der Policy einzugehen würde den Rahmen sprengen.

Der weitere Klassiker ist jedoch die Kennwortrichtlinie (über dessen Anwendung man sich ebenfalls totdiskutieren kann!). Diese ist in der DDP definiert.


Also merke, nutze ich AD, nutze ich immer Policies.
Ob ich will oder nicht!

Nun, jetzt aber!

Für diesen Post ist es Zeit geworden.

Seit 01.10.2011 bin ich MVP im Bereich GPO!


Ja und nu?

Der Blog soll weiterhin GPO und Windows Server beinhalten.

Bleibt es ein Blog, wird es eine eigene Domain?
Ich weiß es nicht! Ich kann es einfach noch nicht sagen.



Achja, noch was fürs Auge ;-)



Donnerstag, 8. September 2011

RemoteApp per GPO verteilen

RemoteApps per GPO verteilen (unter Vista/Win 7)?

Aus der MMC des "RemoteApp-Manager" lassen sich wunderbar MSI-Files
für die Installation der freigegebenen Anwendungen erzeugen.

Nun liegt es nahe, diese per GPO über das AD verteilen zu wollen
(zumindest dann, wenn kein Softwaredistributionswerkzeug im Einsatz ist).


Eine Zuweisung auf Computerebene funktioniert fehlerfrei.
Auf Benutzerebene kann allerdings folgender Fehler auftreten:

Eventlog 107:
"... Die SQL-Abfragesyntax ist ungültig oder wird nicht unterstützt."


Dieser Fehler tritt nur dann auf, wenn UAC (User Account Control) aktiviert ist.

Wie evtl. einigen bekannt ist, lässt sich das Installationsverhalten des Windows-Installers ebenfalls per GPO beeinflussen.
Per Einstellung "Immer mit erhöhten Rechten installieren" lässt sich definieren,
dass alle Installationen (des Windows-Installers) die unter dem Benutzerkontext ausgeführt werden, mit erhöhten Rechten installiert werden.
Diese Einstellung lässt sich allerdings nicht an eine GPO binden und gilt für
alle Installationen.


In diesem speziellen Fall ändert es allerdings nichts an dem eigentlichen Fehler. Auch hier bricht die Installation mit Event-ID 107 ab.

Ob man eine Installation auf Benutzerebene zuweisen sollte,
ist eine umstrittene Frage.

Sollte es dennoch erforderlich sein die RemoteApp auf Benutzerebene zu verteilen, gibt es aktuell nur eine Möglichkeit - UAC ausschalten.