Heimlich still und Leise hat Microsoft im Rahmen des Patchdays im Juni ziemlich elementare Änderungen im Bereich der Gruppenrichtlinienverarbeitung vorgenommen…

Zum Patchday am 14.06.2016  wurde im Bulletin MS16-072 – KB3163622 der  Patch KB3159398 veröffentlicht.

Es gibt im Netz bereits diverse Artikel und Mitigation-Guides… unter anderem:

Who broke my user GPOs?

http://www.gruppenrichtlinien.de/artikel/sicherheitsfilterung-neu-erfunden-ms16-072-patchday-14062016/

 

What’s happen?

Microsoft hat in der clientseitigen Verarbeitung der Gruppenrichtlinien (Server wie auch Workstation-Betriebssysteme) den Sicherheitskontext geändert, in dem die Gruppenrichtlinien ermittelt und gelesen/ausgewertet werden. Das hat zur Folge, dass Benutzergruppenrichtlinien nicht mehr angewendet werden, wenn Sie mittels individueller Sicherheitsgruppe „gefiltert“ werden.

Es geht also um GPO-Konfigurationen aus dem Bereich:

 

Und das Problem tritt auf wenn die GPO im Bereich der Sicherheitsfilterung individuelle Gruppen hinterlegt hat:

 

What was before?

Der Benutzerseitige Teil einer GPO wurde bisher bei einer Aktualisierung der Gruppenrichtlinienkonfiguration (z.B. GPupdate.exe) im Kontext des Benutzers gelesen und ausgewertet. D.h. der angemeldete Benutzer ließt die GPO vom Domänencontroller und übernimmt die Einstellungen.

Auf das oben abgebildete Beispiel ist das möglich, sofern ein Benutzer in der aufgeführten Gruppe ist.

Aus Administrativer Perspektive also: Alles im grünen Bereich! Die GPO mit Benutzerkonfiguration wird auf alle Benutzer angewendet, welche die GPO erhalten sollen…

What is now?

Mit dem oben genannten Patch hat Microsoft diese Verhalten geändert… Die GPO wird nun IMMER vom Computerobjekt (Technisch konkret von „NT AUTHORITY\SYSTEM“) gelesen und ausgewertet. Im Bereich der Computerkonfiguration einer Gruppenrichtlinie war das schon immer so, weshalb sich hier auch keine Änderungen ergeben und der Patch in diesem Bereich keine Auswirkungen zeigt.

Die vom System ausgewerteten Einstellungen der GPO (z.B. Laufwerksmappings, IE-Settings, usw.) werden zur Konfiguration anschließend an den angemeldeten Benutzerkontext übergeben, so dass die Sicherheitsfilterung für die Gruppenrichtlinie auch weiterhin Bestand.

Das Problem an dieser Sache ist nur: Der Computer hat keine Leserechte auf die GPO und kann somit die zu setzenden Einstellungen nicht auswerten.

 

What to do?

Bedeutet das nun für die Zukunft, dass keine Sicherheitsfilterung mehr verwendet werden darf?
Antwort: NEIN, natürlich kann die Sicherheitsfilterung auch weiterhin verwendet werden. Es gibt immer wieder Situationen, in denen man um den Einsatz der Sicherheitsfilterung nicht herumkommt.

Muss ein Admin seine Arbeitsweise ändern?
Antwort: JA. Zumindest dann, wenn keine zusätzliche Konfiguration bzw. Anpassung am Active Directory Schema vorgenommen wird.

 

Quick steps to success – for the individuals

Der schnellste, manuelle Weg zur Lösung des Problems besteht darin auf die betroffene GPO erweiterte Berechtigungen zu setzen. In der Karteikarte „Delegierung“ müssen über den Button „Erweitert“ am besten die Gruppe „Domänencomputer“ mit „Lese“-Berechtigungen hinzugefügt werden.

WICHTIG  zu beachten! Es werden lediglich „Lesen“-Berechtigungen gesetzt. Die Berechtigung „Gruppenrichtlinie übernehmen“ wird ausgespart.

 

Quick steps to success – for the hole company

Der oben beschriebene Weg ist sicher zum schnellen fixen einer einzelnen GPO möglich, aber wahrscheinlich eher umständlich bei 322 vorhandenen GPOs.

Die Berechtigungen können auch ganz einfach über die Powershell gesetzt werden. Mark Heitbrink von Grupenrichtlinien.de hat hierfür in seinem Artikel schon einen fertigen Einzeiler zur Verfügung gestellt.

Set-GPPermissions -All -PermissionLevel GpoRead -TargetName (Get-ADGroup „$((Get-ADDomain).DomainSID)-515“).Name -TargetType Group -ErrorAction Continue

 

The glory way to mitigate in the future

Für alle zukünftig anzulegenden GPOs kann man die Standardberechtigungen für Gruppenrichtlinien im Active Directory Schema anpassen, so dass die Gruppe „Domänencomputer“ zukünftig immer Leserechte auf alle Gruppenrichtlinienobjekte erhält.

Hierzu muss über das MMC-Snapin „ADSI-Editor“ oder „Active Directory Schema“ eine Verbindung Schema hergestellt werden und das Objekt „CN=Group-Policy-Container“ gesucht werden. Das Objekt weist ein Attribut „defaultSecurityDiscriptor“ auf, welches um Eintrag „(A;CI;LCRPLORC;;;DC)“ erweitert werden muss. WICHTIG! Der Eintrag muss am Ende(!) hinzugefügt werden.

 

Das geht natürlich auch mittels Powershell als entsprechend berechtigter Benutzer (Mitglied der Gruppe „Schema-Admins“)

$SchemaMaster = (Get-ADForest).SchemaMaster
$object = „CN=Group-Policy-Container,CN=Schema,CN=Configuration,$((Get-ADDomain).DistinguishedName)“
$GPOSchema = Get-ADObject $object -Properties *
$NewSecDescriptor = „$($GPOSchema.defaultSecurityDescriptor)(A;CI;LCRPLORC;;;DC)“
$GPOSchema | Set-ADObject -Replace @{„defaultSecurityDescriptor“=“$NewSecDescriptor“} -Server
$SchemaMaster

ACHTUNG! Nicht mehrfach ausführen!

 

Redakt.: Andreas Bellstedt