Gruppenrichtlinie greift in OU nicht
Hallo allerseits,
ich stehe derzeit etwas auf dem Schlauch bei der Verteilung von Gruppenrichtlinien.
Ich habe eine GPO für Office 365-Einstellungen auf OU-Ebene angelegt. Eingestellt sind nur Benutzerkonfigurationen. Keine Einträge in der Sicherheitsfilterung, in der Delegation sind Domänencomputer und Authentifizierte Benutzer mit Leserechten (kein "Gruppenrichtlinie übernehmen") eingetragen. Wenn ich mich allerdings mit einem Benutzer aus der entsprechenden OU anmelde und mit über "gpresult /r" die GPOs anzeigen lasse, taucht diese nicht auf, auch nicht in den herausgefilterten. WMI-Filter o.ä. gibt es keinen.
Orientiert habe ich mich an folgendem Beitrag: Sicherheitsfilterung neu erfunden
Wenn ich die GPO auf Domainebene anlege und das ganze über eine Gruppe in der Sicherheitsfilterung zuweise funktioniert es, allerdings würde ich das ganze gerne über die OU verteilen.
Kann mir hier jemand weiterhelfen?
Gruß,
Tobias
ich stehe derzeit etwas auf dem Schlauch bei der Verteilung von Gruppenrichtlinien.
Ich habe eine GPO für Office 365-Einstellungen auf OU-Ebene angelegt. Eingestellt sind nur Benutzerkonfigurationen. Keine Einträge in der Sicherheitsfilterung, in der Delegation sind Domänencomputer und Authentifizierte Benutzer mit Leserechten (kein "Gruppenrichtlinie übernehmen") eingetragen. Wenn ich mich allerdings mit einem Benutzer aus der entsprechenden OU anmelde und mit über "gpresult /r" die GPOs anzeigen lasse, taucht diese nicht auf, auch nicht in den herausgefilterten. WMI-Filter o.ä. gibt es keinen.
Orientiert habe ich mich an folgendem Beitrag: Sicherheitsfilterung neu erfunden
Wenn ich die GPO auf Domainebene anlege und das ganze über eine Gruppe in der Sicherheitsfilterung zuweise funktioniert es, allerdings würde ich das ganze gerne über die OU verteilen.
Kann mir hier jemand weiterhelfen?
Gruß,
Tobias
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 631651
Url: https://administrator.de/forum/gruppenrichtlinie-greift-in-ou-nicht-631651.html
Ausgedruckt am: 14.05.2025 um 13:05 Uhr
10 Kommentare
Neuester Kommentar
Moin,
welches Office/Microsoft 365? Es gibt nur wenige Varianten, die sich mit GPOs steuern lassen, die meisten nicht.
VG
welches Office/Microsoft 365? Es gibt nur wenige Varianten, die sich mit GPOs steuern lassen, die meisten nicht.
VG
Zitat von @chgorges:
Moin,
welches Office/Microsoft 365? Es gibt nur wenige Varianten, die sich mit GPOs steuern lassen, die meisten nicht.
VG
Moin,
welches Office/Microsoft 365? Es gibt nur wenige Varianten, die sich mit GPOs steuern lassen, die meisten nicht.
VG
Per Registry-Key sollte aber trotzdem noch einiges gehen (analog zur Office 2013 H&B).
Moin,
@Looser27 und @chgorges
Ist doch vollkommen egal, wenn die GPO nichtmal bei dem Resultset auftaucht...
@TobiasSchmidt
In die Sicherheitsfilterung müssen die Authenticated Users rein, sonst wird die GPO nicht angefasst.
lg,
Slainte
@Looser27 und @chgorges
Ist doch vollkommen egal, wenn die GPO nichtmal bei dem Resultset auftaucht...
@TobiasSchmidt
In die Sicherheitsfilterung müssen die Authenticated Users rein, sonst wird die GPO nicht angefasst.
lg,
Slainte
Wir verwenden Microsoft Office 365 Business. Prinzipiell funktioniert es ja, wenn ich die GPO auf Domainebene verteile greifen ja auch die Einstellungen. Nur wenn ich auf OU-Ebene wechsel wird die OU nichtmal richtig verteilt.
@TobiasSchmidt
In die Sicherheitsfilterung müssen die Authenticated Users rein, sonst wird die GPO nicht angefasst.
In die Sicherheitsfilterung müssen die Authenticated Users rein, sonst wird die GPO nicht angefasst.
Ich dachte genau das soll man nichtmehr machen? Hab es auch gerade mal getestet, ändert aber leider nichts an dem Problem.
Hi,
richtig ist, dass die Authenticated Users jede GPO mindestens lesen können müssen. Wer sie dann "übernimmt" entscheidest du, indem du z.B. einer Sicherheitsgruppe das "übernehmen"-Recht gibts.
Alternativ setzt du Authenticated Users auf lesen + übernehmen und filterst dann deine Zielgruppe mit den OUs oder bei GPP der Zielgruppenadressierung auf Elementebene.
Oder eine kombination aus dem Methoden. Das musst letztlich du als Admin entscheiden, was du da nimmst.
Wichtig ist, dass Benutzerrichtlinien natürlich auch auf einer OU liegen, die auch Benutzerobjekte beinhalten. Sonst greift da auch nichts.
Mit dem Loopbackverarbeitungsmodus z.B. kannst du Benutzerrichtlinien für bestimmte Computer definieren, indem vorhande Richtlinien entweder ersetzt oder zusammengeführt werden.
MfG
richtig ist, dass die Authenticated Users jede GPO mindestens lesen können müssen. Wer sie dann "übernimmt" entscheidest du, indem du z.B. einer Sicherheitsgruppe das "übernehmen"-Recht gibts.
Alternativ setzt du Authenticated Users auf lesen + übernehmen und filterst dann deine Zielgruppe mit den OUs oder bei GPP der Zielgruppenadressierung auf Elementebene.
Oder eine kombination aus dem Methoden. Das musst letztlich du als Admin entscheiden, was du da nimmst.
Wichtig ist, dass Benutzerrichtlinien natürlich auch auf einer OU liegen, die auch Benutzerobjekte beinhalten. Sonst greift da auch nichts.
Mit dem Loopbackverarbeitungsmodus z.B. kannst du Benutzerrichtlinien für bestimmte Computer definieren, indem vorhande Richtlinien entweder ersetzt oder zusammengeführt werden.
MfG
Zitat von @support-m:
richtig ist, dass die Authenticated Users jede GPO mindestens lesen können müssen.
richtig ist, dass die Authenticated Users jede GPO mindestens lesen können müssen.
Nein - das ist nicht korrekt. Richtig ist, dass das Computerobjekt die Richtlinie lesen können muss. Das kann man auch erreichen, indem man z.B. die Domänencomputer verwendet. Die "Authentifizierten Benutzer" erleichtern die Sache nur.
(...) oder bei GPP der Zielgruppenadressierung auf Elementebene.
Zielgruppenadressierung = langsamWichtig ist, dass Benutzerrichtlinien natürlich auch auf einer OU liegen, die auch Benutzerobjekte beinhalten. Sonst greift da auch nichts.
das wäre jetzt auch meine Idee - wenn die Richtlinie auf Domainebene funktioniert, aber nicht auf OU-Ebene
Gruß
2Wichtig ist, dass Benutzerrichtlinien natürlich auch auf einer OU liegen, die auch Benutzerobjekte beinhalten. Sonst greift da auch nichts.
das wäre jetzt auch meine Idee - wenn die Richtlinie auf Domainebene funktioniert, aber nicht auf OU-Ebene
Das ist auch so angelegt. Aktuell sieht es so aus:
- Domäne
- OU_Standort
- OU_Abteilung
- User 1
Die GPO ist ebenfalls unter OU_Abteilung verknüpft. Sicherheitsfilterungen sind keine eingetragen, es soll ja jeder aus der Abteilung die GPO ziehen. Die Delegierung sieht so aus:
Spielt es eine Rolle wo das Computerkonto in der AD liegt? Dafür gibt es nämlich eine getrennte Struktur.
Ich habe testweise auch mal eine neue GPO in der OU angelegt, auch diese wird nicht gezogen.
Schonmal vielen Dank für die Unterstützung.
Zitat von @Hubert.N:
Richtig ist, dass das Computerobjekt die Richtlinie lesen können muss. Das kann man auch erreichen, indem man z.B. die Domänencomputer verwendet. Die "Authentifizierten Benutzer" erleichtern die Sache nur.
Danke für die Info!Richtig ist, dass das Computerobjekt die Richtlinie lesen können muss. Das kann man auch erreichen, indem man z.B. die Domänencomputer verwendet. Die "Authentifizierten Benutzer" erleichtern die Sache nur.
Gruß
Gruß zurück!
Okay also es liegt scheinbar an der Loopbackverarbeitung in einer anderen Gruppenrichtlinie. Mal schauen wie ich das Wirrwarr da behebe.
