22
GPO - Filterung: Verweigert (Sicherheit)
Ich habe folgendes Problem bei der Anwendung von GPOs.
Ich wollte eine GPO für die Konfiguration der Firewall (Remotedesktop) erzeugen, um das aber als Fehlerbild auszuschließen habe ich auch eine noch einfachere GPO erzeugt in der ich die "Äußerst detaillierte Statusmeldung anzeigen" aktiviert habe.
Nun verhält es sich so, dass die GPO auf einem MS Server 2022 übernommen wird aber bei 2019 und 2016 Filterung: Verweigert (Sicherheit) steht (wenn ich gpresult befrage).
Zu der Config
Was übersehe ich?
Ich wollte eine GPO für die Konfiguration der Firewall (Remotedesktop) erzeugen, um das aber als Fehlerbild auszuschließen habe ich auch eine noch einfachere GPO erzeugt in der ich die "Äußerst detaillierte Statusmeldung anzeigen" aktiviert habe.
Nun verhält es sich so, dass die GPO auf einem MS Server 2022 übernommen wird aber bei 2019 und 2016 Filterung: Verweigert (Sicherheit) steht (wenn ich gpresult befrage).
Zu der Config
- Server sind in der gleichen OU
- Server sind in der gleichen Gruppe die für die Sicherheitsfilterung benutzt wird
- unter Delegierung habe ich den Domänen-Computer die Lese-Rechte gegeben
- Authentifizier Benutzer wurde bei Sicherheitsfilterung entfernt (deswegen ja auch der Punkt darüber)
- kein Loopback an
- keine GPO die an den Punkten vorher was ändert
Was übersehe ich?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 11200784690
Url: https://administrator.de/contentid/11200784690
Ausgedruckt am: 25.11.2024 um 07:11 Uhr
22 Kommentare
Neuester Kommentar
Hallo,
der Beschreibung nach haben die Computer kein Recht, die GPO anzuwenden. Das ist zu unterscheiden vom Leserecht.
Grüße
Richard
der Beschreibung nach haben die Computer kein Recht, die GPO anzuwenden. Das ist zu unterscheiden vom Leserecht.
Grüße
Richard
Hallo Richard,
danke für deine schnelle Antwort.
Über das Recht die GPO anzuwenden habe ich mir noch nie Gedanken gemacht. Ich dachte das kommt quasi über die Domänenzugehörigkeit oder wenigstens über den Eintrag System unter Delegierung. Bei der LAPS-GPO habe ich das 1 zu 1 so wie oben beschrieben konfiguriert und es funktioniert (auf einen anderen Server in der gleichen OU). Die Sicherheitsfilterung ist für mich dazu da, die Systeme nicht in verschiedene OUs aufsplitten zu müssen.
An welcher Stelle wird denn das Recht auf Anwendung gesetzt?
Auf allen Servern funktioniert auch die WSUS-GPO aber die hat auch keine Sicherheitsfilterung.
Grüße
Benjamin
danke für deine schnelle Antwort.
Über das Recht die GPO anzuwenden habe ich mir noch nie Gedanken gemacht. Ich dachte das kommt quasi über die Domänenzugehörigkeit oder wenigstens über den Eintrag System unter Delegierung. Bei der LAPS-GPO habe ich das 1 zu 1 so wie oben beschrieben konfiguriert und es funktioniert (auf einen anderen Server in der gleichen OU). Die Sicherheitsfilterung ist für mich dazu da, die Systeme nicht in verschiedene OUs aufsplitten zu müssen.
An welcher Stelle wird denn das Recht auf Anwendung gesetzt?
Auf allen Servern funktioniert auch die WSUS-GPO aber die hat auch keine Sicherheitsfilterung.
Grüße
Benjamin
Man übersieht dieses Recht leicht, weil es automatisch gesetzt wird, wenn man die Sicherheitsfilterung (auf dem ersten Tab) einrichtet, d.h. von Authentifizierte Benutzer auf eine Sicherheitsgruppe ändert. Das Problem ist dann eher umgekehrt, dass dann nur diese Gruppe Lesen- & Anwenden-Rechte hat, und alle anderen nicht mal Lese-Rechte, was oft unerwünscht ist.
Das Resultat dieser Automatik über die Sicherheitsfilterung ist, dass die Gruppe unter Delegierung mit dem Recht "Lesen (durch Sicherheitsfilterung)" aufgeführt wird. Wenn Du in der Delegierung auf "Erweitert" gehst, wirst Du sehen, dass es zwei Rechte, lesen und anwenden (oder so ähnlich) sind. Da du offenbar nur das Leserecht manuell unter Delegierung hinzugefügt hast, fehlt das Recht zum Anwenden.
Das Resultat dieser Automatik über die Sicherheitsfilterung ist, dass die Gruppe unter Delegierung mit dem Recht "Lesen (durch Sicherheitsfilterung)" aufgeführt wird. Wenn Du in der Delegierung auf "Erweitert" gehst, wirst Du sehen, dass es zwei Rechte, lesen und anwenden (oder so ähnlich) sind. Da du offenbar nur das Leserecht manuell unter Delegierung hinzugefügt hast, fehlt das Recht zum Anwenden.
Hi,
Prinzipale, welche in der Sicherheitsfilterung gelistet sind, sind all jene, denen das Recht zur Übernahme der GPO gewährt wurde. bzw. umgekehrt: Alle Prinzipale, welche man dort einträgt, erhalten dieses Recht gewährt. Man muss da also nichts doppelt machen.
Ich könnte mir vorstellen, dass Du das zu schnell nach dem Hinzufügen der Computer zu dieser Gruppe getestet hast.
Also entweder diese Computer durchstarten oder unter Anmeldung von SYSTEM "klist purge" ausführen (z.B. über Scheduled Task oder mittels psexec). Danach gpupdate.
E.
Prinzipale, welche in der Sicherheitsfilterung gelistet sind, sind all jene, denen das Recht zur Übernahme der GPO gewährt wurde. bzw. umgekehrt: Alle Prinzipale, welche man dort einträgt, erhalten dieses Recht gewährt. Man muss da also nichts doppelt machen.
Ich könnte mir vorstellen, dass Du das zu schnell nach dem Hinzufügen der Computer zu dieser Gruppe getestet hast.
Also entweder diese Computer durchstarten oder unter Anmeldung von SYSTEM "klist purge" ausführen (z.B. über Scheduled Task oder mittels psexec). Danach gpupdate.
E.
Hallo Richard,
wenn ich unter Delegierung -> Erweitert ... gucke, hat die Gruppe Lesen und Gruppenrichtlinie übernehmen.
Das sollte dann ja das Ausführungsrecht sein oder?
wenn ich unter Delegierung -> Erweitert ... gucke, hat die Gruppe Lesen und Gruppenrichtlinie übernehmen.
Das sollte dann ja das Ausführungsrecht sein oder?
Hallo emeriks,
prinzipiell habe ich heute Vormittag schon eine Weile ausprobiert und nach jeder Änderung die gpupdate /force ausgeführt. Weiterhin sind zwei der drei Server seit gestern in der Gruppe.
Eigentlich sollte das doch ausreichen.
prinzipiell habe ich heute Vormittag schon eine Weile ausprobiert und nach jeder Änderung die gpupdate /force ausgeführt. Weiterhin sind zwei der drei Server seit gestern in der Gruppe.
Eigentlich sollte das doch ausreichen.
Ich weiß jetzt nicht, wie lange es dauert, bis ein durchlaufender Computer seine geänderte Gruppenmitgliedschaft aktualisiert. Im Zweifelfall würde ich das wie schon von mir beschrieben manuell machen.
Zitat von @Benji87:
Hallo Richard,
wenn ich unter Delegierung -> Erweitert ... gucke, hat die Gruppe Lesen und Gruppenrichtlinie übernehmen.
Das sollte dann ja das Ausführungsrecht sein oder?
Hallo Richard,
wenn ich unter Delegierung -> Erweitert ... gucke, hat die Gruppe Lesen und Gruppenrichtlinie übernehmen.
Das sollte dann ja das Ausführungsrecht sein oder?
Ja, das stimmt dann.
Naja mit gpupdate /force macht er das ja direkt nochmal, macht an der Stelle keinen Unterschied zum Neustart.
Zitat von @Benji87:
Naja mit gpupdate /force macht er das ja direkt nochmal, macht an der Stelle keinen Unterschied zum Neustart.
Naja mit gpupdate /force macht er das ja direkt nochmal, macht an der Stelle keinen Unterschied zum Neustart.
Doch, der Computer braucht für alle gruppenbasierten ACL ein Kerberos-Ticket mit der jeweiligen Gruppenmitgliedschaft, d.h. ein neues, wenn die verwendete Mitgliedschaft neu ist. Entweder durch klist purge oder Neustart.
Beratungsresistent?
Zitat von @c.r.s.:
Doch, der Computer braucht für alle gruppenbasierten ACL ein Kerberos-Ticket mit der jeweiligen Gruppenmitgliedschaft, d.h. ein neues, wenn die verwendete Mitgliedschaft neu ist. Entweder durch klist purge oder Neustart.
Zitat von @Benji87:
Naja mit gpupdate /force macht er das ja direkt nochmal, macht an der Stelle keinen Unterschied zum Neustart.
Naja mit gpupdate /force macht er das ja direkt nochmal, macht an der Stelle keinen Unterschied zum Neustart.
Doch, der Computer braucht für alle gruppenbasierten ACL ein Kerberos-Ticket mit der jeweiligen Gruppenmitgliedschaft, d.h. ein neues, wenn die verwendete Mitgliedschaft neu ist. Entweder durch klist purge oder Neustart.
Ich muss zugeben, dass ich an Kerberos-Tickets in den Zusammenhang nicht gedacht habe, schon weil der erste Server die GPO nach dem gpupdate /force gleich bekommen hat.
Weiterhin bin ich davon ausgegangen, dass das Ticket ja sowieso nach 10 Stunden (spätestens) erneut werden und ich das somit ausschließen kann.
Das klist purge als SYSTEM hat zwar jetzt geholfen aber ich stelle mir natürlich die Frage, wie ich das in einer produktiven Umgebung umsetzen soll, da möchte ich ja eine Gruppenrichtlinie zuweisen und den Server nicht neustarten oder mich darauf verbinden um den Befehl anzusetzen?
Kann man ansonsten die SYSTEM-Tickets irgendwie sehen, mit klist allgemein scheinen die ja dann nicht aufgelistet zu werden?
Und warum haben die 10 Stunden maximale Lebensdauer des Tickets das nicht korrigiert?
Kann man ansonsten die SYSTEM-Tickets irgendwie sehen, mit klist allgemein scheinen die ja dann nicht aufgelistet zu werden?
Und warum haben die 10 Stunden maximale Lebensdauer des Tickets das nicht korrigiert?
Zitat von @Benji87:
Kann man ansonsten die SYSTEM-Tickets irgendwie sehen, mit klist allgemein scheinen die ja dann nicht aufgelistet zu werden?
Kann man ansonsten die SYSTEM-Tickets irgendwie sehen, mit klist allgemein scheinen die ja dann nicht aufgelistet zu werden?
klist ticketsUnd warum haben die 10 Stunden maximale Lebensdauer des Tickets das nicht korrigiert?
Hier ist es schön erklärt:
Understanding Kerberos Tickets
A renewal is literally taking the ticket the KDC received, recalculating the start/end times within the renew-until window, resigning the PAC, and re-encrypting the ticket. There is no update to ticket contents. It still has all the same SIDs from before.
To that end, service ticket issuance is also a copy of the TGT PAC, so when you say "gimme a ticket to that file share" the KDC will not query for your group membership again. It'll just see your TGT, copy the contents to the new service ticket and return that.
So, if you get a TGT with a 7-day renewal window then it's definitely possible to get membership information that's 7 days out of date.
For completeness, there is a critical distinction between how machine logons work and user logons work. Users get fresh TGTs every time you lock/unlock so your group membership information is updated regularly. This usually means you don't have to reboot or logout to get things working. It just takes a minute for things to replicate to all the DCs and then the next time you lock/unlock you'll get a fresh TGT with new group details.
Machine logons do it once after startup and have no other natural trigger to get a new TGT. If you're so inclined you can run klist purge -li 0x3e7 from an elevated command prompt to purge the machine tickets and cause it to request a new ticket the next time it needs it.
Diesen Erneuerungszeitraum kannst du per GPO festlegen. Per Default sind das 7 Tage. Wenn du also nichts änderst wird der Computer erst nach 7 Tagen ein neues Ticket mit aktualisierten Gruppenmitgliedschaften holen.
Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos PolicyGruß Strods
Aber die Frage von @Benji87 ist nicht ganz unberechtigt.
Wenn Du also den Fall hast, dass Du Server nicht in ausreichend nahliegender Zeit durchstarten kannst, dann hast Du 2 Optionen:
E.
Wenn Du also den Fall hast, dass Du Server nicht in ausreichend nahliegender Zeit durchstarten kannst, dann hast Du 2 Optionen:
- Temporär neben der neu erstellten Sicherheitsgruppe jeden einzelnen der betreffenden Computer mit deren Computerkonten direkt in den Sicherheitsfilter eintragen. Nach 3 h können die Computerkonten da wieder raus.
- Eine 2. GPO, welche für alle Computer gilt und einen sofortigen Task verteilt. Ausführen als "SYSTEM", ausführen "klist purge". Damit sollten nach max. 2h alle durchlaufenden Computer ihre Ticket erneuert haben. Nach 3 h kannst Du diese GPO wieder deaktivieren.
E.
Danke erstmal für eure Unterstützung, auch wenn es irgendwie nicht ganz verständlich ist, dass ich im schlimmsten Fall nach 7 Tagen erst die neue Gruppenzugehörigkeit erhalte. Beim Client kann ich das ja bzgl. des Neustarts verstehen auch wenn das beim Notebook schon so eine Sache ist aber beim Server...
Hat jemand aus den Gründen die Zeit auf einen Tag runter gesetzt oder ist das eher nicht zu empfehlen?
Hat jemand aus den Gründen die Zeit auf einen Tag runter gesetzt oder ist das eher nicht zu empfehlen?
Zitat von @Benji87:
Beim Client kann ich das ja bzgl. des Neustarts verstehen auch wenn das beim Notebook schon so eine Sache ist aber beim Server...
Machst du bei deinen Servern keine Updates? Habt ihr keine Wartungsintervalle?Beim Client kann ich das ja bzgl. des Neustarts verstehen auch wenn das beim Notebook schon so eine Sache ist aber beim Server...
Computer-Gruppenmitgliedschaften ändern sich ja in der Regel nicht täglich, so dass in der Regel kein Problem darstellt wenn man den temporär für den Übergang direkt in die ACL einträgt und das Teil dann im Wartungsintervall neu startet. Kannst du das nicht dann fehlt dir eine entsprechende High Availability deiner Dienste.
Hat jemand aus den Gründen die Zeit auf einen Tag runter gesetzt oder ist das eher nicht zu empfehlen?
Erzeugt halt mehr Last an den DCs wenn die häufiger die Mitgliedschaften für neue Tickets abfragen müssen.
Naja beim Update der Server sind wir dann ja aber wieder eher bei > 7 Tage.
Ich weiß jetzt ehrlich gesagt nicht mehr was du noch mehr willst, die Optionen die du für diese Fälle hast wurden dir oben ja schon genannt.
Ich habe das Thema ja auch entsprechend auf gelöst gesetzt und nur nochmal angefragt ob aus den ersichtlichen Gründen jemand von 7 Tagen auf einen Tag umgestellt hat. Dabei bin ich natürlich davon ausgegangen, dass das es eine Höhere Last für den/die DCs bedeutet.
klist purge funktioniert doch wunderbar. Meist hat man irgendein Fernwartungs-/Deployment-/Automatisierungs-Tool, das dies ad hoc ausführen kann. Ein geplanter Task macht es innerhalb eines GPO-Refresh-Zyklus genauso.
Zitat von @c.r.s.:
klist purge funktioniert doch wunderbar. Meist hat man irgendein Fernwartungs-/Deployment-/Automatisierungs-Tool, das dies ad hoc ausführen kann. Ein geplanter Task macht es innerhalb eines GPO-Refresh-Zyklus genauso.
klist purge funktioniert doch wunderbar. Meist hat man irgendein Fernwartungs-/Deployment-/Automatisierungs-Tool, das dies ad hoc ausführen kann. Ein geplanter Task macht es innerhalb eines GPO-Refresh-Zyklus genauso.
Ich bin da immer für Anregungen offen. Ich hatte mal in meinem alten Bereich das Windows Admin Center im Einsatz aber jetzt sind es bei mir nicht mehr so viele Server.
Was ich aus der Diskussion auch mitgenommen habe, ist die Notwendigkeit klist pruge als System auszuführen.
