14
Leserechte für Gruppenrichtlinien global vergeben
Hallo in die Runde,
unter Windows Server 2012 R2 habe ich das Problem, dass einige Gruppenrichtlinien nicht übernommen werden. Im Bericht von gpresult steht als Gund "Zugriff nicht möglich" drin.
Ich habe in mehreren Foren den Hinweis gefunden, dass man das Leserecht für "Authentifizierte Benutzer" setzen soll. Das habe ich testhalber mal für eine Richtlinie gemacht (Richtlinie anklicken -> Delegierung -> Hinzufügen -> Benutzer wählen -> Berechtigung "Lesen". Das hat auch geklappt. Die Richtlinie ist aus der Liste verschwunden. Aber ich müsste das für alle Richtlinien von Hand machen. Wenn ich das in der OU eintrage, wird es nicht auf die Richtlinie vererbt, obwohl "Alle Unterobjekte" angegeben wurde.
Wie kann man das Leserecht global vergeben? Mal abgesehen davon, wie kommt sowas überhaupt zustande? Ich habe in den Rechten noch nie drin rum gefummelt.
unter Windows Server 2012 R2 habe ich das Problem, dass einige Gruppenrichtlinien nicht übernommen werden. Im Bericht von gpresult steht als Gund "Zugriff nicht möglich" drin.
Ich habe in mehreren Foren den Hinweis gefunden, dass man das Leserecht für "Authentifizierte Benutzer" setzen soll. Das habe ich testhalber mal für eine Richtlinie gemacht (Richtlinie anklicken -> Delegierung -> Hinzufügen -> Benutzer wählen -> Berechtigung "Lesen". Das hat auch geklappt. Die Richtlinie ist aus der Liste verschwunden. Aber ich müsste das für alle Richtlinien von Hand machen. Wenn ich das in der OU eintrage, wird es nicht auf die Richtlinie vererbt, obwohl "Alle Unterobjekte" angegeben wurde.
Wie kann man das Leserecht global vergeben? Mal abgesehen davon, wie kommt sowas überhaupt zustande? Ich habe in den Rechten noch nie drin rum gefummelt.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 300457
Url: https://administrator.de/contentid/300457
Printed on: April 26, 2024 at 10:04 o'clock
14 Comments
Latest comment
Hi,
Diesen siehst Du nur über z.B. ADSIEDIT oder wenn Du in der ADUC MMC die erweiterte Ansicht aktivierst.
E.
unter Windows Server 2012 R2 habe ich das Problem, dass einige Gruppenrichtlinien nicht übernommen werden. Im Bericht von gpresult steht als Gund "Zugriff nicht möglich" drin.
Das deutet aber auf einen allgemeinen Fehler bei der Rechtevergabe hin. Also handwerklicher Fehler. Alle Benutzer/Computer, welche eine GPO anwenden sollen, benötigen auch das Recht zum lesen dieser. Alle anderen Benutzer/Computer nicht.Ich habe in mehreren Foren den Hinweis gefunden, dass man das Leserecht für "Authentifizierte Benutzer" setzen soll. Das habe ich testhalber mal für eine Richtlinie gemacht (Richtlinie anklicken -> Delegierung -> Hinzufügen -> Benutzer wählen -> Berechtigung "Lesen". Das hat auch geklappt. Die Richtlinie ist aus der Liste verschwunden.
Was heißt "aus der Liste verschwunden"?Aber ich müsste das für alle Richtlinien von Hand machen. Wenn ich das in der OU eintrage, wird es nicht auf die Richtlinie vererbt, obwohl "Alle Unterobjekte" angegeben wurde.
Das ist logisch, weil die GPO kein Unterobjekt einer OU ist. In der OU ist nur ein gplink-Objekt, welches auf die GPO verweist. Wenn Du Berechtigungen für alle GPO auf diese Weise setzen willst, dann musst Du über den Container "CN=Policies,CN=System,DC=domain,DC=tld" gehen.Diesen siehst Du nur über z.B. ADSIEDIT oder wenn Du in der ADUC MMC die erweiterte Ansicht aktivierst.
E.
Das deutet aber auf einen allgemeinen Fehler bei der Rechtevergabe hin. Also handwerklicher Fehler. Alle Benutzer/Computer, welche eine GPO anwenden sollen, benötigen auch das Recht zum lesen dieser. Alle anderen Benutzer/Computer nicht.
Und genau da macht Windows offensichtlich einen Fehler. Inzwischen tippe ich sogar auf einen Bug.Nach weiterem rum probieren bin ich inzwischen darauf gestoßen, dass das Problem nur bei Domänen-Admins besteht. Diese stehen sowieso schon in der Liste der Delegierungen und somit scheint kein korrekter Berechtigungseintrag zu erfolgen. Wende ich die GPO auf andere Gruppen oder Nutzer an, so wird ein korrekter Eintrag in den Delegierungen erzeugt und alles funktioniert wunderbar. Es betrifft also nur GPOs, die rein auf Domänen-Admins angewendet werden sollen.
Ich habe in mehreren Foren den Hinweis gefunden, dass man das Leserecht für "Authentifizierte Benutzer" setzen soll. Das habe ich testhalber mal für eine Richtlinie gemacht (Richtlinie anklicken -> Delegierung -> Hinzufügen -> Benutzer wählen -> Berechtigung "Lesen". Das hat auch geklappt. Die Richtlinie ist aus der Liste verschwunden.
Was heißt "aus der Liste verschwunden"?Aber ich müsste das für alle Richtlinien von Hand machen. Wenn ich das in der OU eintrage, wird es nicht auf die Richtlinie vererbt, obwohl "Alle Unterobjekte" angegeben wurde.
Das ist logisch, weil die GPO kein Unterobjekt einer OU ist. In der OU ist nur ein gplink-Objekt, welches auf die GPO verweist. Wenn Du Berechtigungen für alle GPO auf diese Weise setzen willst, dann musst Du über den Container "CN=Policies,CN=System,DC=domain,DC=tld" gehen.Diesen siehst Du nur über z.B. ADSIEDIT oder wenn Du in der ADUC MMC die erweiterte Ansicht aktivierst.
Es betrifft also nur GPOs, die rein auf Domänen-Admins angewendet werden sollen.
Geht folgendes?- Alle betreffenden Domänen-Admins in eine OU.
- Eine GPO erstellen und die Standardfilterung belassen (Authentifizierte Benutzer)
- GPO an die OU mit den Domänen-Admins verlinken.
Wird diese GPO für Domänen-Admins angewendet?
Die Standardfilterung funktioniert. Nur wenn ich auf Domänen-Admins filtere klappt es nicht.
Meine "Lösung" war als pragmatische Ansatz gedacht.
Wenn ich Benutzer und GPO in einer OU habe, funktioniert es noch nicht. Verschiebe ich den Rechner auch in diese OU, dann klappt es. Muss also irgendwie mit Rechnerberechtigungen zusammen hängen.
Wenn ich Benutzer und GPO in einer OU habe, funktioniert es noch nicht. Verschiebe ich den Rechner auch in diese OU, dann klappt es. Muss also irgendwie mit Rechnerberechtigungen zusammen hängen.
Wenn es ein Berechtigungsproblem wäre, dann würde die Position eines Kontos (Computer oder User, egal) in der OU-Struktur keine Auswirkungen haben.Reden wir hier von einer GPO mit Benutzereinstellungen oder von einer mit Computereinstellungen?
Falls Benutzereinstellungen: Das würde bedeuten, dass auf dem Computer Loopback "ersetzen" aktiv ist.
Falls Computereinstellungen: Was soll das dann mit den Domänen-Admins.
Es sind Benutzereinstellungen. Loopback ist nicht aktiv.
Verknüpfe ich die GPO in der Unter-OU, wo der Rechner definiert ist, klappt es. Füge ich Domänencomputer bei der Delegierung Leserechte hinzu, funktioniert es nicht.
Verknüpfe ich die GPO in der Unter-OU, wo der Rechner definiert ist, klappt es. Füge ich Domänencomputer bei der Delegierung Leserechte hinzu, funktioniert es nicht.
Es sind Benutzereinstellungen. Loopback ist nicht aktiv.
Vielleicht war es mal für diesen Computer aktiv und die GPO wurde einfach gelöscht, ohne eine Gegenrichtlinie zu schreiben.Setze es doch mal explizit auf "deaktiviert". Dann GPO auf dem Computer aktualsieren, Computer wieder in andere OU schieben, booten, dann anmelden.
Verknüpfe ich die GPO in der Unter-OU, wo der Rechner definiert ist, klappt es.
s.o.Das kann nur so zusammenhängen.
Füge ich Domänencomputer bei der Delegierung Leserechte hinzu, funktioniert es nicht.
Du meinst, statt das Computerobjekt in die betreffende OU zu schieben?Füge ich Domänencomputer bei der Delegierung Leserechte hinzu, funktioniert es nicht.
Du meinst, statt das Computerobjekt in die betreffende OU zu schieben?Auch Loopback explizit deaktivieren hat nix gebracht. Dürfe auch nicht drin gewesen sein, da ich in einer VM teste, die ich immer per Snapshot zurück setze. Aber auf die Idee mit der VM testen kam ich erst, weil die Richtlinien nicht alle am realen PC übernommen wurden. Ist also nicht nur an einem Rechner so.
Füge ich Domänencomputer bei der Delegierung Leserechte hinzu, funktioniert es nicht.
Du meinst, statt das Computerobjekt in die betreffende OU zu schieben?Auch Loopback explizit deaktivieren hat nix gebracht. Dürfe auch nicht drin gewesen sein, da ich in einer VM teste, die ich immer per Snapshot zurück setze. Aber auf die Idee mit der VM testen kam ich erst, weil die Richtlinien nicht alle am realen PC übernommen wurden. Ist also nicht nur an einem Rechner so.
Du willst mir erzählen ...
OU1
- OU2
- Die GPO ist an OU1 verlinkt und die Verlinkung ist aktiv.
- In OU2 ist die GPO-Vererbung nicht deaktiviert.
- Wenn das Computer-Objekt in OU1 ist, dann werden die Benutzereinstellungen der GPO bei Anmeldung an diesem Computer übernommen.
- Und wenn das Computer-Objekt in OU2 ist, dann werden die Benutzereinstellungen der GPO bei Anmeldung an diesem Computer nicht übernommen.
- Ohne weitere Änderungen zwischen 3. und 4.
- An OU2 ist keine GPO verlinkt, welche die Einstellungen der an OU1 verlinkten GPO wieder aufhebt.
Sorry, aber das ist nicht logisch. Entweder machst Du hier - unabsichtlich/unwissendlich - falsche Angaben, oder wir reden aneinander vorbei.
Leider ist es exakt so. Deshalb sage ich ja, es scheint sich um einen Bug zu handeln. Das passiert auch nur, wenn es sich um eine GPO handelt, die für Domänen-Admins ist. Setze ich stattdessen "Authentifizierte Benutzer" ein, so wird sie übernommen.
Der Benutzer ist in OU1 definiert, der Computer in OU2.
Du darfst es gerne mal ausprobieren. Ich nutze Server 2012 R2 Standard mit aktuellen Updates. Wäre tatsächlich mal interessant, ob das generell so ist. Aber ich weiß nicht, was da falsch sein könnte.
Der Benutzer ist in OU1 definiert, der Computer in OU2.
Du darfst es gerne mal ausprobieren. Ich nutze Server 2012 R2 Standard mit aktuellen Updates. Wäre tatsächlich mal interessant, ob das generell so ist. Aber ich weiß nicht, was da falsch sein könnte.
Blöde Frage vielleicht: Aber Du bist Dir sicher, dass der Benutzer, mit welchem Du testest, dann auch Mitglied der Domänen-Admins ist?
Jupps, ist er. Ich bin jetzt aber einen Schritt weiter. Ich muss explizit auch bei der Sicherheitsfilterung Domänencomputer eintragen (auch wenn es eine reine Benutzerregel ist). Wenn ich Domänencomputer bei der Delegierung zum Lesen berechtige, reicht es seltsamerweise nicht aus.