Jump to content
michelo82

GPOs wirken nicht additiv

Recommended Posts

Hallo,

und zwar möchte ich mich lokal oder mit RDP mit einem personalisierten Admin-Account an den DC's anmelden.

Dazu habe ich eine "Delta-Richtlinie" zur DDCP angelegt.

 

Ist die Verknüpfungsreihenfolge nach der DDCP wirkt meine neu erstellte Richtlinie nicht.

Ist die Verknüpfungsreihenfolge vor der DDCP wirkt meine DDCP nicht :dizzy:.

Ich war der Annahme, dass die Policys additiv arbeiten und ich somt die Default Domain Controller Policy mit meiner neuen Delta-Richtlinie einfach ergänzen kann.

 

853154176_2020-11-2011_12_49-DC01-VMwareWorkstation.thumb.png.2fd208f7703e102c0b617121b8eb8ab0.png

 

1771179900_2020-11-2011_12_05-DC01-VMwareWorkstation.png.811892f537897d5859ea720f509171ed.png

 

 

 

Mache ich etwas falsch? Ich wollte nicht unbedingt die Default Domain Controller Policy verändern.

 

 

MfG

Michi

Share this post


Link to post
vor 8 Minuten schrieb michelo82:

Ist die Verknüpfungsreihenfolge nach der DDCP wirkt meine neu erstellte Richtlinie nicht.

Ist die Verknüpfungsreihenfolge vor der DDCP wirkt meine DDCP nicht :dizzy:.

Also wirkt sie überhaupt nicht? Naja dann brauchst du dir über den Rest ja noch keine Sorgen machen, sondern müßtest erstmal den Fehler finden. Ich würde vielleicht auch nicht unbedingt mit der OU Domaincontroller bei solchen Tests beginnen. ;)

Share this post


Link to post

Moin,

 

ich wäre an der Stelle bei Mark "gruppenrichtlinien.de" Heitbrink und würde das direkt in der DDCP eintragen. Es geht hier ja offenbar um Einstellungen, die direkt und ausschließlich auf die DCs wirken sollen. Da würde ich mir den modularen Krempel einfach sparen.

 

Die Gruppen würde ich hier allerdings anders bauen. Ich entwärfe eine DL-Gruppe "DL-DC-Local-Logon", der ich das Recht zuwiese. Danach müsste ich das Recht (und das GPO) nie wieder anfassen, sondern verwaltete ausschließlich die Gruppenmitgliedschaften.

Für RDP-Anmeldung gibt es sogar schon eine Gruppe, da muss man an das Recht überhaupt nicht ran.

 

Edit: Hier noch der Link zu Marks Artikel - und der Hinweis, dass er sogar einen handfesten Vorteil nennt, genau diese Einstellung in der DDCP zu machen.

[Default Domain Policy und Default Domain Controllers Policy ändern oder nicht? - Gruppenrichtlinien]
https://www.gruppenrichtlinien.de/artikel/default-domain-policy-und-default-domain-controllers-policy-aendern-oder-nicht

Und es steht auch da, dass die eigene Policy, wenn vorhanden, oben stehen muss ...


Gruß, Nils

 

Edited by NilsK

Share this post


Link to post
vor 19 Minuten schrieb NorbertFe:

Also wirkt sie überhaupt nicht?

Doch die neue Richtlinie wirkt sobald ich diese in der Reihenfolge vor die DDCP schiebe. Soweit wäre das verständlich.

Allerdings hebelt das verschieben der Reihenfolge die DDCP aus!

 

Ich habe zum testen ein weiteres Test-Konto in die Gruppe der Server-Operatoren gesteckt. Die dürfen sich nämlich ebenfalls am DC lokal anmelden.

326666670_2020-11-2011_32_49-DC01-VMwareWorkstation.png.f4e04cb9cb6b27628afa63731c322cb1.png

 

Nach dem verschieben der Reihenfolge, dürfen diese sich nicht mehr anmelden.

 

 

vor 19 Minuten schrieb NorbertFe:

Ich würde vielleicht auch nicht unbedingt mit der OU Domaincontroller bei solchen Tests beginnen. ;)

Es ist ein Test-AD in einer VM. Ich habe nämlich schon bei meinen letzten versuchen eine Audit-Policy anzulegen gemerkt, dass danach die vorher getätigten Audit-Einstellung der DDCP nicht mehr galten. Die entsprechenden Events waren dann im Evenlog nicht mehr zu finden, weil meine vorherigen Einstellungen in der DDCP wieder überschrieben waren.

 

 

vor 16 Minuten schrieb NilsK:

Moin,

 

ich wäre an der Stelle bei Mark "gruppenrichtlinien.de" Heitbrink und würde das direkt in der DDCP eintragen. Es geht hier ja offenbar um Einstellungen, die direkt und ausschließlich auf die DCs wirken sollen. Da würde ich mir den modularen Krempel einfach sparen.

Habe ich eben gelesen. Das wäre eine Möglichkeit.

Aber warum geht es denn nicht additiv? Habe das auch so in der Fachliteratur gelesen.

 

 

vor 16 Minuten schrieb NilsK:

Für RDP-Anmeldung gibt es sogar schon eine Gruppe, da muss man an das Recht überhaupt nicht ran.

Welche wäre das?

 

 

 

Danke schonmal für die sehr schnellen Antworten :)

Edited by michelo82

Share this post


Link to post

Moin,

 

vor 5 Minuten schrieb michelo82:

Aber warum geht es denn nicht additiv?

weil GPOs (leider) nicht nur einen Umsetzungsmechanismus haben, sondern mehrere Dutzend. Und die funktionieren nicht einheitlich.

 

Ein guter Bekannter und ich sind uns gerade nicht ganz sicher, wir vermuten aber, dass die Zuweisung von Benutzerrechten einfach nicht additiv bzw. modular ist. Dort gilt dann das Prinzip "Last Writer Wins".

 

Andere Einstellungen sind durchaus modular, vor allem die unter den Administrativen Vorlagen.

 

Gruß, Nils

PS. falls du mit der "Fachliteratur" einen Autor mit den Initialen T.J. meinst - dem würde ich praktisch nix glauben. Da fehlt oft die Sorgfalt.

Edited by NilsK

Share this post


Link to post
vor 3 Minuten schrieb michelo82:

Aber warum geht es denn nicht additiv? Habe das auch so in der Fachliteratur gelesen.

Zeig mal die Fachliteratur. Ich bin der Meinung es geht eben an der Stelle mit den Security Policies nicht additiv.

vor 15 Minuten schrieb michelo82:

Allerdings hebelt das verschieben der Reihenfolge die DDCP aus!

 

Ja, für mich auch logisch. Ich hätte die "Additivität" nicht erwartet.

Share this post


Link to post

Da steht aber auch nix für Delta GPO bei den Security Richtlinien. ;) Und selbst wenn, steht da: Die zuletzt abgearbeitete Richtlinie bestimmt den Wert. Wo genau liest du was von additiv?

Share this post


Link to post

Moin,

 

sehe ich auch so. Das Missverständnis ist vermutlich: Einstellungen in verschiedenen Bereichen der Gruppenrichtlinien können durchaus "additiv" sein bzw. sind es in der Regel. Hier ergibt das Konzept der "Delta-Richtlinien" durchaus Sinn (übrigens ist das so eine Erfindung der Autoren, das ist kein allgemein üblicher Ausdruck). Einstellungen für denselben Eintrag sind aber in aller Regel nicht "additiv". In dem Beispiel, das wir hier diskutieren, geht es ja um genau einen Wert (nämlich die Angabe, wer ein bestimmtes Benutzerrecht erhält). Der wird durch die GPOs vollständig gesetzt. Die Komponente, die das umsetzt, geht nicht die einzelnen Teile des Werts durch und prüft, was es da nun wie zusammenbasteln müsste. Hier also "ganz oder gar nicht", wenn man so will.

 

Das ist möglicherweise in dem Buch nicht so ausdrücklich beschrieben. Sowas liegt dann daran, dass die Autoren selbst nicht auf diesen Gedanken bzw. auf diese Lesart gekommen sind. (Ansonsten kann man den Autoren durchaus vertrauen, Peter kenne ich sogar persönlich. Und dem Verlag natürlich auch. ;-))

 

Gruß, Nils

Share this post


Link to post
vor 8 Minuten schrieb NilsK:

Einstellungen für denselben Eintrag sind aber in aller Regel nicht "additiv". In dem Beispiel, das wir hier diskutieren, geht es ja um genau einen Wert (nämlich die Angabe, wer ein bestimmtes Benutzerrecht erhält). Der wird durch die GPOs vollständig gesetzt. Die Komponente, die das umsetzt, geht nicht die einzelnen Teile des Werts durch und prüft, was es da nun wie zusammenbasteln müsste. Hier also "ganz oder gar nicht", wenn man so will.

 

Das ist möglicherweise in dem Buch nicht so ausdrücklich beschrieben.

Genau das ist die Erklärung! Danke.

 

vor 38 Minuten schrieb NorbertFe:

Wo genau liest du was von additiv?

Ich habe es mir zusammengereimt ;)

 

Erstens das gelesene aus dem Buch + 1967695589_2020-11-2012_47_50-Gruppenrichtlinien-EinrichtenVerwaltenFehlersuche-Windows_Gruppenrichtli.thumb.png.2f5f3c33a1493c73ea1d3d9744cb2019.png

 

Und das Missverständnis war perfekt!

 

 

Ein anderes Beispiel:

Mir ist noch unklar, warum meine Auditing-Einstellung durch meine neue Richtlinie außer Kraft gesetzt wurden.

 

564198114_2020-11-2012_50_42-ADMINHOST1-VMwareRemoteConsole.thumb.png.60f567773e8f7f43f3009a294f13a837.png

 

Hier habe ich die Erweiterte Überwachungskonfiguration bearbeitet.

Danach waren die Audit-Events aus der DDCP nicht mehr im Ereignislog zu sehen. (z.b. 4771).

 

405743055_2020-11-2012_50_10-ADMINHOST1-VMwareRemoteConsole.thumb.png.39e66fa06cb8baa106da27c0cb7259ee.png

Edited by michelo82

Share this post


Link to post

Moin,

 

kann ich dir bei dem Detail nicht genau sagen, aber im Wesentlichen wird es dasselbe Phänomen sein. Vielleicht kommt an der Stelle noch dazu, dass die beiden Konfiguratoinsmethoden für die Überwachung nicht richtig kompatibel miteinander sind.

 

Falls du gerade dabei bist, dir Wissen anzueignen: Nimm dir weniger komplexe Beispiele. Du hast hier gerade zwei Stellen, die "speziell" sind. Wie gesagt - mehrere Dutzend Mechanismen bei der GPO-Abarbeitung.

 

Falls es um konkret umzusetzende Einstellungen geht: Nimm dir viel Zeit, eine gute Laborumgebung, die du auf einen definierten Stand zurücksetzen kannst, und befasse dich erst mit den Mechanismen selbst und dann mit der Verteilung.

 

Gruß, Nils

 

Share this post


Link to post
vor 10 Stunden schrieb NilsK:

ich wäre an der Stelle bei Mark "gruppenrichtlinien.de" Heitbrink und würde das direkt in der DDCP eintragen.

Ich nicht - DDP und DDCP läßt man einfach, wie sie sind... Warum? Sie haben wellknown GUIDs, dcgpofix überschreibt sie, und Änderungen im Domain Head an PW-Policies wandern in die DDP zurück. Nur eine eigene "DDP" kann das übersteuern...

 

Zum Thema "Benutzerrechte additiv statt last writer wins": https://evilgpo.blogspot.com/2015/04/wer-bin-ich-und-was-darf-ich.html

 

@michelo82 Du hast das falsche Buch gelesen :-)

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


Werbepartner:



×
×
  • Create New...