nidavellir
Goto Top

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.

01 lockout

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.

02 sperrungsrichtlinie

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.

03 net accounts

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:

04 abgelehnt

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

Content-Key: 12768399543

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

Printed on: July 20, 2024 at 06:07 o'clock

Member: DerWoWusste
DerWoWusste Jun 06, 2024 at 15:54:45 (UTC)
Goto Top
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.
Member: emeriks
emeriks Jun 07, 2024 at 13:39:39 (UTC)
Goto Top
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.