Ja, ich weiß, ich erzähle jetzt hier nichts brandneues mehr. Aber vielleicht geht es anderen so wie mir diese Woche, daher also dieser Artikel. Aber erst mal von Anfang an:
Ich habe diese Woche in unserer ActiveDirectory Umgebung eine neue GPO angelegt. Mein Ziel war, damit eine neue Mailsignatur an alle Benutzer auszurollen. Die nötigen Einstellungen befinden sich im Benutzer-Zweig der GPOs, daher spreche ich gerne von einer “Benutzer-GPO”, was man bei mir auch immer im Namen sieht. Um das Ganze erstmal sinnvoll testen zu können, habe ich auf die Sicherheitsfilterung zurückgegriffen. Ihr wisst schon, damit kann man die GPO statt auf die gesamte verknüpfte OU auf einzelne Benutzer oder Gruppen anwenden. Also habe ich die “Authentifizierten Benutzer” entfernt, und stattdessen mich und einen weiteren Kollegen dort eingetragen:
Das Problem
Leider wirkte sich die GPO dann nicht wie gewünscht aus. Auffällig war aber, dass ich plötzlich auch das Verzeichnis, in dem sich die GPO-Daten und damit auch das Skript, dass die GPO ausführen sollte, befanden, nicht mehr lesen konnte. Selbst mit einem Domänen-Admin-Konto nicht! Sobald ich die “Authentifizierten Benutzer” bzw. in meinem Fall “Authenticated Users” wieder hinzugefügt hatte, konnte ich die Dateien wieder lesen. Natürlich hätte ich damit aber auch die GPO für die gesamte GPO ausgerollt.
Die Ursache
Ein bisschen Recherche im Internet brachte mich dann auf die Ursache des Problems und damit auch auf dessen Lösung:
Microsoft hatte durch ein Update, dass bereits im Juni 2016 erschienen war, eine wesentliche Arbeitsweise von GPOs geändert:
Bisher war es so, dass für das Wirksamwerden von Computer-GPOs das Computerkonto für die GPO das Lesen-Recht haben musste und bei Benutzer-GPOs das Benutzerkonto. Das Ganze passte auch zur Logik, dass Computer-Richtlinien nur auf Computerkonten wirken und Benutzer-Richtlinien nur auf Benutzerkonten (Ausnahme: Loopback-Verarbeitung). Das hat man auch nicht geändert. Was allerdings geändert wurde ist, dass auch bei Benutzer-Richtlinien das Computerkonto die Leserechte auf die GPO braucht.
Wenn man entweder keine Benutzer-GPOs benutzt oder bei diesen immer die “Authenticated Users” in der “Security Filtering” drin lässt (womit dann faktisch nur noch eine Steuerung über die verknüpfte OU oder über WMI-Filter möglich wird, wenn man nicht vom “verweigern” der Berechtigungen Gebrauch machen will) ändert sich für einen selbst nichts.
Wenn man aber so wie ich gerne mal auch bei Benutzer-GPOs auf die Gruppen- oder Benutzerkonten-bezogene Filterung zurückgreift, dann muss man diese Änderung unbedingt kennen!
Die Lösung
Die Lösung des Problem ist eigentlich recht einfach – wenn man die Ursache kennt. Das Computerkonto des Computers, an dem der jeweilige Benutzer arbeitet muss also in die Lage versetzt werden, die GPO zu lesen. Da man nicht immer weiß, wer gerade wo arbeitet und sich das ja auch täglich ändern könnte, bleibt fast nur, den “Domänen-Computern” das Leserecht zu geben. Und das funktioniert über den Reiter “Delegation” bzw. “Delegierung”:
Hier findet ihr noch den Blog-Artikel bei Microsoft, der mich zum Problem und dessen Lösung brachte:
https://blogs.technet.microsoft.com/askpfeplat/2016/07/05/who-broke-my-user-gpos/
8 Comments
