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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 6188497559
Url: https://administrator.de/forum/default-domain-policy-6188497559.html
Ausgedruckt am: 31.03.2025 um 13:03 Uhr
10 Kommentare
Neuester Kommentar
Moin
Nanana
- 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.
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ß
Zitat von @MrHeisenberg:
weil in der Default wie gesagt möchte ich nix angreifen ohne vorab sicher zu sein dass alles geht.
weil in der Default wie gesagt möchte ich nix angreifen ohne vorab sicher zu sein dass alles geht.
Nanana
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.
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ß
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- ...
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- ...
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...
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?
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?
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.
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.