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/
Danke!
Nicht nur fuer das HowTo, sondern eher fuer die ausfuehrliche und sehr gut verstaendliche schilderung. Hatte das Problem mehrfach in der Vergangenheit. Leider hatte ich immer nur Anleitungen gefunden, in denen Stand: Tu dies, tu jenes.
Nach deiner Erklaerung weiss ich jetzt wo das herkommt und habs damit auch verstanden. Somit muss ich es nicht auswendig lernen, verstehen reicht.
MfG
Danke für das Feedback!
Ein anderer Ansatz wäre, über die Delegation das Recht für „Authentifizierte Benutzer“ auf „Lesen“ (nicht „Lesen(durch Sicherheitsfilterung)“) einzustellen und im Reiter Bereich dann einfach die Gruppen/Benutzer in die Sicherheitsfilterung aufzunehmen, für die diese GPO angewendet werden soll. Wenn man auch die Domänen-Computer in verschiedenen Gruppen eingeteilt hat, ist das ev. einfacher.
MFG
Auch ein guter Ansatz… Danke!
Hallo, eines ist mir noch nicht klar: Computerkonto-Leserecht wird benötigt. Aber warum funktioniert das dann, wenn man nur ‚Authentifizierte Benutzer‘ hinzufügt und keine Computer?
Hallo Uwe. Der Grund ist recht einfach: In der Gruppe „Authentifizierte Benutzer“ sind auch alle Domänen-Computer enthalten! 🙂 LG, Haiko
Hallo, ich bin durch Zufall auf diesen Post gestoßen. Sowohl die manuellen Lesenrechte als auch das hinzufügen der Domänen-Computer funktioneren. Danke!
Wie verhält es sich mit den Computern, aus der gleichen Organisation aber in jeweils unterschiedlichen Domänen? Sind diese „fremden“ Computer auch Mitglied von „Domänen-Computer“? Falls nicht, wäre eine Gruppe „Authentifizierte Computer“ praktisch 😉
VG, Arnd
Servus!
Nach meinem Verständnis sind die domänenfremden Computer (egal ob selbe Gesamtstruktur oder trusted Domain) NICHT Bestandteil der „Domain Computers“ / „Domänen-Computer“. So entnehme ich es auch der Microsoft-Doku:
„This group can include all computers and servers that have joined the domain, excluding domain controllers. By default, any computer account that is created automatically becomes a member of this group.“
(https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/active-directory-security-groups#bkmk-domaincomputers)
Soweit ich weiß gibt es keine Gruppe wie „Authentifizierten Computer“ – ABER: Man könnte „Authentifizierte User“ (die ja ALLE Computer aller Domänen der Gesamtstruktur und alle Computer aus trusted Domains enthält) berechtigen und dann „Domänen-Benutzer“ verbieten / ausschließen.
LG
Haiko