mrheisenberg
Goto Top

Default Domain Policy

Moin Leute,

bin gerade auf was draufgekommen, was nicht so geil ist, bei uns gibt's derzeit keine Kontosperrungsrichtlinien... in der Default Domain Policy wurde hier die mit 0 angegeben, so jetzt war ich so schlau, hab in meiner Test OU eine GPO erstellt, wo genau nach Eingabe X der User gesperrt wird, Testgerät und User via gpupdate /force die neue GPO gegeben, und probiert, was ich aber nicht Behirnt habe, die Default Policy überschreibt mir die Einstellungen.

Ich will/muss die Richtlinie vorab Testen damit mir kein Hoppala in den Einzelnen OU´s passiert, weil es schwer ist welcher Dienst mit welchen User läuft und so einiges mehr, kurzum ich will vorab die Einzelnen kritischen OU´s ausnehmen und die Richtlinie nicht gleich über die Gesamte Domain ausrollen.

Wir wäre eure Vorgangsweise damit Ihr nicht gleich in der Default Policy herumdoktort und Gefahr lauf hier sämtliche Dienste welche mit einen "Roboter-User" zu sperren.
Mir fehlen leider viele Infos über die Vorgangsweisen in der Firma da mir der IT Leiter so einige Fragen nicht beantworten kann...

Aufgrund diesen Umstandes will ich Vorab im kleinen Rahmen Testen und dann pöh a pöh die Richtlinien auf die gesamte Struktur ausweiten.


Grüße

Content-Key: 6188497559

Url: https://administrator.de/contentid/6188497559

Printed on: April 19, 2024 at 20:04 o'clock

Member: Spirit-of-Eli
Spirit-of-Eli Mar 02, 2023 at 13:20:33 (UTC)
Goto Top
Moin,

aus meiner Sicht ist genau das eines der wenigen Dinge, die tatsächlich an der Default Domain Policy geändert werden.
Ansonsten bleibt diese unberührt.

Wenn du dir unsicher bist, solltest du diese Konfig erst in einer Testumgebung prüfen bevor du sie ausrollst.

Gruß
Spirit
Member: MrHeisenberg
MrHeisenberg Mar 02, 2023 at 13:25:36 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:

Moin,

aus meiner Sicht ist genau das eines der wenigen Dinge, die tatsächlich an der Default Domain Policy geändert werden.
Ansonsten bleibt diese unberührt.

Wenn du dir unsicher bist, solltest du diese Konfig erst in einer Testumgebung prüfen bevor du sie ausrollst.

Gruß
Spirit

Hoi,

dass ist eben meine Frage, dass die Einstellung in der Default Policy zu ändern ist, bzw. die einzige Richtlinie ist welche dort eingestellt werden soll ist mir klar, also würdest du mehr oder weniger einen zweiten Domaincontroller in Betrieb nehmen um die GPO zu testen, weil in der Default wie gesagt möchte ich nix angreifen ohne vorab sicher zu sein dass alles geht.
LG
Member: Spirit-of-Eli
Spirit-of-Eli Mar 02, 2023 at 13:33:19 (UTC)
Goto Top
Wenn du mit "einen zweiten Domaincontroller" eine separate abgeschottete Testumgebung meinst.
Dann ja.

Ich meine das ganze ist jetzt kein Hexenwerk. Für dich selbst bringt dich das ganze dem Verständnis näher.
Member: Looser27
Looser27 Mar 02, 2023 at 13:44:10 (UTC)
Goto Top
Alternativ könntest Du auch eine GPO erstellen, in der Du die gewünschte Einstellung vornimmst, diese an alle entsprechend ausrollst und in der Richtlinienverarbeitung "erzwungen" auswählst. Damit sollten die Einstellungen nicht mehr überschrieben werden.
Member: Hubert.N
Hubert.N Mar 02, 2023 at 14:04:45 (UTC)
Goto Top
Moin

Zitat von @MrHeisenberg:
weil in der Default wie gesagt möchte ich nix angreifen ohne vorab sicher zu sein dass alles geht.

Nanana face-wink - Mal Mut zu Lücke... Wenn Du an der Richtlinie zur Kontosperrung schraubst, dann wird das AD schon nicht explodieren. Das ist nun wirklich Standard.
Eine Testumgebung wird Dir da auch nicht viel bringen, denn wenn es irgendwo Probleme gibt, dann durch irgendeine vergurkte Konfiguration an irgendeiner Stelle, die Du in der Testumgebung ja nicht hättest.


Zitat von @Looser27:
Alternativ könntest Du auch eine GPO erstellen, in der Du die gewünschte Einstellung vornimmst, diese an alle entsprechend ausrollst und in der Richtlinienverarbeitung "erzwungen" auswählst. Damit sollten die Einstellungen nicht mehr überschrieben werden.

Nein - das geht nicht. Man kann keine alternative Kennwortrichtlinien über OUs erstellen. Kennwortrichtlinien können ausschließlich über die Default Domain Policy oder über Fine Grained Password Policys erzeugt werden.

Gruß
Member: Spirit-of-Eli
Spirit-of-Eli Mar 02, 2023 updated at 14:32:58 (UTC)
Goto Top
Ausschließlich in der DDP stimmt nicht.

Granularer lässt sich das ganze ich meine über das AD Verwaltungscenter konfigurieren. Dort gibt es eine explizite Richtliniene.

Edit:
Hier wird der Unterschied erklärt:
https://www.escde.net/blog/konfiguration-der-passwortrichtlinien-active- ...
Member: Hubert.N
Hubert.N Mar 02, 2023 at 14:35:30 (UTC)
Goto Top
Zitat von @Spirit-of-Eli:
Ausschließlich in der DDP stimmt nicht.

Habe ich auch nicht geschrieben

Granularer lässt sich das ganze ich meine über das AD Verwaltungscenter konfigurieren.

Das sind unterm Strich genau die von mir genannten "Fine Grained Password Policys". Viele Wege führen nach Rom...
Member: DerWoWusste
DerWoWusste Mar 02, 2023 at 16:29:08 (UTC)
Goto Top
Hi.

Die klassische Account-Lockout-Policy wird für Domänenkonten auf dem DC festgelegt und gilt für alle Konten. Tests gibt es somit nicht! Was man da testen wollen könnte, ist mir schleierhaft. Wenn Deine Roboterkonten automatisch falsche Kennwöter eingeben würden, würden deren Dienste/Tasks doch niemals laufen! Also wo ist bitte die Gefahr?
Member: MrHeisenberg
MrHeisenberg Mar 03, 2023 at 07:19:08 (UTC)
Goto Top
Zitat von @DerWoWusste:

Hi.

Die klassische Account-Lockout-Policy wird für Domänenkonten auf dem DC festgelegt und gilt für alle Konten. Tests gibt es somit nicht! Was man da testen wollen könnte, ist mir schleierhaft. Wenn Deine Roboterkonten automatisch falsche Kennwöter eingeben würden, würden deren Dienste/Tasks doch niemals laufen! Also wo ist bitte die Gefahr?

Moin,

mein Problem ist folgendes, ich soll die Richtline bearbeiten und hab aber keinen Plan was hier in der IT-Umgebung so kreucht und fleucht... eine PW-Policy ist nix schlimmes ist mir bewusst, aber ich hab keinen Bock dass sich ein User Sperrt weil dieser sein Passwort automatisiert falsch eingibt.
Hintergrund: In meiner alten Firma hatten wir eine Produktionsuser, dieses war über eine PS gesteuert, wo ja ist mir bewusst: sein Passwort im Klartext eingegeben war, der User musste angemeldet sein damit die Robotik funktionierte.
Soweit kein Problem, Passwort war im Skript falsch drinnen, störe niemanden da ja keine Kontosperrung eingerichtet war, so unser damaliger Sysadmin stellte die Policy um, und naja bescheidener Zeitpunkt Freitag um 12:00 , so was passierte? Der User wurde gesperrt, somit ging nix mehr ans Netzwerk, und die Produktion stand von Freitag bis Montag... deswegen bin ich da etwas vorsichtig, da mir keiner sagen kann läuft da ein Skript oder ein Dienstuser...
Deswegen auch die evtl. aus deiner Sicht blöde Frage, nur ich bin da etwas vorsichtig geworden, verständlich, weil die Aktion hat den damaligen Admin seinen Job gekostet... abgesehen davon, war auch eine bescheidene Firma.
Member: DerWoWusste
DerWoWusste Mar 03, 2023 at 08:10:02 (UTC)
Goto Top
Es wurde dir schon erklärt, dass du mit den klassischen Policies nur alle oder keinen erreichst und somit NICHT testen kannst. Du kannst nun umstellen auf Passwort settings objects (PSO, auch bekannt als fine-grained password policies),
https://woshub.com/fine-grained-password-policy-in-windows-server-2012-r ...
Damit kannst Du pro Konto oder pro Gruppe festlegen, welche Kennwort- und Kontosperrungsrichtlinien gelten.