2
Delegierung User entsperren - Problem mit User State und Lock-Status
Hallo allerseits,
ich möchte gern an zwei Kollegen das Recht delegieren User zu entsperren. Hierfür bin ich nach dem Beitrag [1] vorgegangen, der passenderweise vor ein paar Tagen erschienen ist.
[1] https://www.windowspro.de/wolfgang-sommergut/berechtigung-fuer-entsperre ...
Umgebung:
- 2 Domänencontroller, Windows Server 2019, aktueller Patchstand
- Domäne ist ca. 8-9 Jahre alt und wurde vor ~3 Jahren vom 2012er (oder 2012R2) Stand migriert
Nachdem ich die Anleitung abgearbeitet hatte, wollte ich das ganze testen und die Einweisung der Kollegen vorbereiten. Ich habe hierfür einen Test-User genommen und mit falschem Passwort mehrfach versucht am Terminalserver anzumelden. Nach 3 Versuchen erfolgte die erwartete Sperrung.
In "lockoutstatus.exe" habe ich den Status nach jedem Fehlversuch beobachtet. Nach dem dritten Versuch sprang der "User State" auf "Not Locked (Auto Unlocked)". Das macht doch so aber keinen Sinn, oder? Zumal in den Eigenschaften des Users unter dem Reiter "Konto" klar die Sperrung zu sehen ist.
Im Kontextmenü von "lockoutstatus.exe" ist die Option "Unlock Account" ausgegraut. Unabhängig davon ob ich das mit einem Standard-User, dem ich das Recht delegiert habe, prüfe oder mit meinem Domain-Admin in meiner separaten Admin-VM.
Ich habe dann die "Default Domain Policy" geprüft, in der die Kontosperrungsrichtlinien definiert sind, und testweise die "Kontensperrungsschwelle" von 3 auf 5 erhöht.
In meinen weiteren Tests erfolgte die Sperrung allerdings weiterhin nach 3 Versuchen und dem oben beschriebenen "Auto Unlocked".
Ich habe dann auf beiden DCs (einmal mit GUI, einmal Core) "gpupdate /force" ausgeführt und mittels "net accounts /domain" die Werte geprüft. Aus meiner Sicht haben die DCs hier die richtigen Werte gezogen.
Auch auf dem Terminalserver habe ich gpupdate ausgeführt.
Die Ausgaben von "gpresult" auf dem dcserver01 und dem Terminalserver sehen aus meiner Sicht gut aus. Unter "Kontorichtlinien/Kontosperrungsrichtlinien" stehen die 5 Anmeldeversuche und je 10 Minuten wie in der GPO definiert. Die "Default Domain Policy" wird unter "Angewendete Gruppenrichtlinienobjekte" aufgeführt, unter "Abgelehnte Gruppenrichtlinienobjekte" ist folgendes zu sehen:
Auch jetzt, ~1,5h nach den ersten Tests ist das Ergebnis gleich. 3 Fehlversuche und der User wird gesperrt.
Wo könnte der Fehler liegen? Welche weiteren Infos kann ich euch zum Eingrenzen liefern?
Viele Grüße
Nidavellir
ich möchte gern an zwei Kollegen das Recht delegieren User zu entsperren. Hierfür bin ich nach dem Beitrag [1] vorgegangen, der passenderweise vor ein paar Tagen erschienen ist.
[1] https://www.windowspro.de/wolfgang-sommergut/berechtigung-fuer-entsperre ...
Umgebung:
- 2 Domänencontroller, Windows Server 2019, aktueller Patchstand
- Domäne ist ca. 8-9 Jahre alt und wurde vor ~3 Jahren vom 2012er (oder 2012R2) Stand migriert
Nachdem ich die Anleitung abgearbeitet hatte, wollte ich das ganze testen und die Einweisung der Kollegen vorbereiten. Ich habe hierfür einen Test-User genommen und mit falschem Passwort mehrfach versucht am Terminalserver anzumelden. Nach 3 Versuchen erfolgte die erwartete Sperrung.
In "lockoutstatus.exe" habe ich den Status nach jedem Fehlversuch beobachtet. Nach dem dritten Versuch sprang der "User State" auf "Not Locked (Auto Unlocked)". Das macht doch so aber keinen Sinn, oder? Zumal in den Eigenschaften des Users unter dem Reiter "Konto" klar die Sperrung zu sehen ist.
Im Kontextmenü von "lockoutstatus.exe" ist die Option "Unlock Account" ausgegraut. Unabhängig davon ob ich das mit einem Standard-User, dem ich das Recht delegiert habe, prüfe oder mit meinem Domain-Admin in meiner separaten Admin-VM.
Ich habe dann die "Default Domain Policy" geprüft, in der die Kontosperrungsrichtlinien definiert sind, und testweise die "Kontensperrungsschwelle" von 3 auf 5 erhöht.
In meinen weiteren Tests erfolgte die Sperrung allerdings weiterhin nach 3 Versuchen und dem oben beschriebenen "Auto Unlocked".
Ich habe dann auf beiden DCs (einmal mit GUI, einmal Core) "gpupdate /force" ausgeführt und mittels "net accounts /domain" die Werte geprüft. Aus meiner Sicht haben die DCs hier die richtigen Werte gezogen.
Auch auf dem Terminalserver habe ich gpupdate ausgeführt.
Die Ausgaben von "gpresult" auf dem dcserver01 und dem Terminalserver sehen aus meiner Sicht gut aus. Unter "Kontorichtlinien/Kontosperrungsrichtlinien" stehen die 5 Anmeldeversuche und je 10 Minuten wie in der GPO definiert. Die "Default Domain Policy" wird unter "Angewendete Gruppenrichtlinienobjekte" aufgeführt, unter "Abgelehnte Gruppenrichtlinienobjekte" ist folgendes zu sehen:
Auch jetzt, ~1,5h nach den ersten Tests ist das Ergebnis gleich. 3 Fehlversuche und der User wird gesperrt.
Wo könnte der Fehler liegen? Welche weiteren Infos kann ich euch zum Eingrenzen liefern?
Viele Grüße
Nidavellir
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 12768399543
Url: https://administrator.de/forum/delegierung-user-entsperren-problem-mit-user-state-und-lock-status-12768399543.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
2 Kommentare
Neuester Kommentar
Dass der Nutzer gesperrt ist, siehst Du ja. Dass das Tool "not locked (auto-unlocked" verkündet, ist Auslegungssache: wenn nach 10 Minuten automatisch entsperrt wird dann ist das Konto ja auf Sicht nicht gelockt, da es auto-unlocked wird. Soweit ist das erklärbar.
Warum jedoch 3 Versuche reichen, statt 5, musst Du wohl Microsoft fragen. Du machst nichts verkehrt.
Warum jedoch 3 Versuche reichen, statt 5, musst Du wohl Microsoft fragen. Du machst nichts verkehrt.
Hi,
aus Sicht des DC ist nur interessant, wieviel fehlerhafte Anmeldeversuche bei ihm ankommen, nicht wieviele der Benutzer glaubt, ausgelöst zu haben. Wir hatten hier auch mal ne Anwendung über LDAP-Anbindung, welche nach einem(!) Fehlversuch sofort die Sperrung des AD-Kontos verursacht hat, weil es die Anmeldung mehrfach versucht hat.
Also würde ich an Deiner Stelle die Logs der DC's überprüfen, wieviel "Fehlgeschlagen"-Einträge da produziert werden, wenn Du 3x das Passwort falsch eingegeben hast.
E.
aus Sicht des DC ist nur interessant, wieviel fehlerhafte Anmeldeversuche bei ihm ankommen, nicht wieviele der Benutzer glaubt, ausgelöst zu haben. Wir hatten hier auch mal ne Anwendung über LDAP-Anbindung, welche nach einem(!) Fehlversuch sofort die Sperrung des AD-Kontos verursacht hat, weil es die Anmeldung mehrfach versucht hat.
Also würde ich an Deiner Stelle die Logs der DC's überprüfen, wieviel "Fehlgeschlagen"-Einträge da produziert werden, wenn Du 3x das Passwort falsch eingegeben hast.
E.
