Sicherheitsfilterung neu erfunden - MS16-072 - Patchday 14.06.2016
MS16-072 - KB3163622 - Patch KB3159398 - Patchday 14.06.2016
Nach vielen Jahren hat Microsoft eine massive Änderung im Übernahme Prozess der Richtlinien mit diesem Patch integriert.
- Microsoft Security Bulletin MS16-072 - Important
- MS16-072: Security update for Group Policy: June 14, 2016 (Siehe Known Issues)
- Ask Premier Field Engineering (PFE) Platforms | Who broke my user GPOs?
Bislang war es so:
Das Benutzerobjekt liest die für ihn gültigen Richtlinien im AD und es findet je nach Komponente ein Wechsel des Sicherheitskontextes statt und eine anschliessende Übergabe der zu importierenden Einstellungen an das NT AUTHORITY\SYSTEM.
Der initiale Lesevorgang wird durch das Benutzerobjekt vollzogen, d.h. der Computer benötigt KEINERLEI Rechte an der Richtlinie. Sein Job (Aufruf/Verwendung der DLLs), den er zu erledigen hat, wird ihm einfach ausgedrückt vom Benutzer übergeben.
Neu mit MS16-072:
Das Computerobjekt, an dem sich der Benutzer anmeldet liest jetzt die Richtlinien für den Benutzer und das NT AUTHORITY\SYSTEM übergibt die zu importierenden Einstellungen an den Benutzer, wenn er diese in seinem Benutzerkontext ausführen soll, z.B.: Anmelde Skripte und Laufwerksmapping. Der initiale Lesevorgang findet nun also mit dem Computerkonto und nicht mehr mit dem Benutzer statt.
Wo ist das Problem?
Viele Admins entfernen die "Authentifizierten Benutzer" aus der Sicherheitsfilterung der Richtlinie, um die Richtlinien für eine spezielle Benutzersicherheitsgruppe zu filtern. In dem Moment wird der ACL Eintrag der Authentifizierten Benutzer komplett aus dem GP Objekt entfernt.
Das hat bis zum Update 3159398 prima funtkioniert. Der Computer hat in dieser Konfiguration KEINE Leserechte mehr an dem Objekt. Er gehört auch zu den Authentifizierten Benutzer. Sobald das Update 3159398 eingespielt ist, werden KEINE Benutzerrichtlinien mehr angewendet von Richtlinien, die über diesen Weg gefiltert werden.
Von Heute auf Morgen stirbt der Gruppenrichtlinien Prozess und der Administrator ist sich keiner Schuld bewusst.
Akute Korrektur Lösung:
Alle betroffenen Richtlinien werden angefasst und die Authentifizierte Benutzer werden über den Reiter Delegation mit LESE Rechten hinzugefügt. Alternativ kann auch die Sicherheitsgruppe DomänenComputer verwendet werden. Wichtig ist nur, das es über den Reiter Delegation geschieht, da nur so das Recht LESEN gesteuert werden kann. Ein Hinzufügen auf der Sicherheitsfilterung ist immer Lesen und ÜBERNEHMEN, letzteres wollen wir auf keinen Fall.
Etwas bequemer geht es per Script für alle GP OBjekte auf einmal:
New Group Policy Patch MS16-072– “Breaks” GP Processing Behavior
Oder noch besser: Fakten schaffen mit dem OneLiner weiter unten ...
Lösungen für die Zukunft:
a) Änderung der eigenen Arbeitsweise. Für die Sicherheitsfilterung wird ab heute IMMER der Reiter Delegation genutzt und den Authentifizierten Benutzern wird nur das Recht ÜBERNEHMEN entzogen, damit das LESE Recht erhalten bleibt.
Ist ja nicht so, als ob ich das nicht schon seit Jahren so predige :-)
Filtern von Gruppenrichtlinien anhand von Benutzergruppen, WMI und Zielgruppenadressierung
b) Veränderung des defaultSecurityDiscriptors des Group-Policy-Containers.
Das ist vielleicht etwas scary, aber für neue Gruppenrichtlinien Objekte wird dann die Sicherheitsgruppe der DomänenComputer automatisch mit LESE Rechten hinzugefügt und es wird immer funktionieren, auch wenn die Authentifizierten Benutzer komplett entfernt sind. Der Computer bleibt mit Leserechten erhalten, bzw. steht schon drin.
ADSI-Editor öffnen und zum Schema verbinden dann das Objekt "CN=Group-Policy-Container" suchen.Attribut: defaultSecurityDiscriptor öffnen und diesen Eintrag am Ende(!) hinzufügen: (A;CI;LCRPLORC;;;DC)
... witzigerweis sind die "DC" die DomänenComputer, nicht die DomänenController. Die Controller werden mit "ED" abgekürzt (Enterprise Domaincontrollers), siehe: Security Descriptor Description Language
Wer das umgesetzt hat, der möchte sicherlich auch den Eintrag auf jeder schon vorhandenen Richtlinie integriert haben. Damit Richtlinien, die heute mit dem Script vom Darren korrigiert wurden auch in Zukunft immer funktionieren werden:
Ein One-Liner, Sprachneutral
Set-GPPermissions -All -PermissionLevel GpoRead -TargetName (Get-ADGroup "$((Get-ADDomain).DomainSID)-515").Name -TargetType Group -ErrorAction Continue
Sonderfall: MultiTennant Active Directory
Wer als Hoster ein AD für viele Kunden betreibt, die sich nicht unter einander sehen dürfen und wo auch die Inhalte der Gruppenrichtlinien unter das Stichwort Datenschutz fallen, denen bleibt nichts anderes übrig als für alle COMPUTER des Kunden eine eigene Sicherheitsgruppe zu pflegen und diese mit LESE Rechten zu bestücken.