Benutzer sperrt sich immer wieder im Active Directory Contoller
Hallo liebe Community,
ich nutze kaum Foren, aber dieses mal komme ich alleine echt nicht weiter.
Kurz zum Umfeld, in dem ich arbeite.
Virtualisierter SBS-2011 für AD, Exchange, DNS, DHCP + mehrere virtualisierter Datenbankserver + Terminalserver usw., dazu kommen ca. 90 Clients (68 Benutzer) mit 98% OS Windows 10 (Version 1703).
Seit mehreren Monaten, hat ein Benutzer ein Problem, jeden morgen (und nach jedem Rechner sperren) kann er sich nicht mehr anmelden, wenn ich mir den Benutzer im Konsolenstamm anschaue, steht unter Konto "Heben Sie die Kontosperrung auf, Das Konto ist derzeit auf dem Active-Directory-Domänencontroller gesperrt". --> Immer und immer wieder, ich setze den Hacken drücke OK, Benutzer kann sich anmelden.
Bin nicht fündig geworden woran das liegen könnte.
Wir haben "TestUser" angelegt, ich habe einen von denen bereits umgeschrieben, damit der Kollege ein quasi frisches nicht korrumpiertes Benutzerkonto nutzen kann, nach dem war auch knapp 1 1/2 Monate Ruhe... seit vergangener Woche tritt das Problem wieder auf.
Im Log auf dem SBS kann ich keinen passenden Eintrag finden...
Hat jemand einen Rat?
ich nutze kaum Foren, aber dieses mal komme ich alleine echt nicht weiter.
Kurz zum Umfeld, in dem ich arbeite.
Virtualisierter SBS-2011 für AD, Exchange, DNS, DHCP + mehrere virtualisierter Datenbankserver + Terminalserver usw., dazu kommen ca. 90 Clients (68 Benutzer) mit 98% OS Windows 10 (Version 1703).
Seit mehreren Monaten, hat ein Benutzer ein Problem, jeden morgen (und nach jedem Rechner sperren) kann er sich nicht mehr anmelden, wenn ich mir den Benutzer im Konsolenstamm anschaue, steht unter Konto "Heben Sie die Kontosperrung auf, Das Konto ist derzeit auf dem Active-Directory-Domänencontroller gesperrt". --> Immer und immer wieder, ich setze den Hacken drücke OK, Benutzer kann sich anmelden.
Bin nicht fündig geworden woran das liegen könnte.
Wir haben "TestUser" angelegt, ich habe einen von denen bereits umgeschrieben, damit der Kollege ein quasi frisches nicht korrumpiertes Benutzerkonto nutzen kann, nach dem war auch knapp 1 1/2 Monate Ruhe... seit vergangener Woche tritt das Problem wieder auf.
Im Log auf dem SBS kann ich keinen passenden Eintrag finden...
Hat jemand einen Rat?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 344397
Url: https://administrator.de/forum/benutzer-sperrt-sich-immer-wieder-im-active-directory-contoller-344397.html
Ausgedruckt am: 22.12.2024 um 14:12 Uhr
22 Kommentare
Neuester Kommentar
Hallo.
Wie verhalt sich das hier:
hierzu?
Ist das betroffene Konto so eines, oder hat der User ein eigenes auf seinen Namen, das kein anderer mitbenutzt?
Falls er ein eigenes Konto hat, das nur er benutzt:
- kann es sein, daß der beim PWD eintippen so hippelig ist, daß er's jedesmal 3 x mal falsch eintippt, ADHS gibt's auch bei Erwachsenen
- ernsthaft: stell' Dich beim PWD tippen mal neben ihn und sieh' ihm zu, was er macht, viell. ist ein "a" im PW und er erwischt jedesmal die Feststelltaste und bemerkt die Bildschirmmeldung dazu nicht
Welches Log? Hoffentlich meinst Du das Security-Log. Wenn jemand ein falsches PWD bis zur Sperre hämmert, zeigt das die Ereignis-ID 4740 eindeutig an.
Bist Du der einzige Domänen-Admin? Sicher, daß kein normaler Nutzer irgendwann mal das Kennwort eines administrativen Domänenkontos erfahren hat? Jemand, der hier Mobbing gegen den betroffenen Kollegen durch ständige Sabotage betreibt? Und der zufällig, als es mal 1 1/2 Monate keine Probleme gab, im Australien-Urlaub war?
Doch selbst das ist nicht nötig: Wenn ein Kollege den Windows-Benutzernamen des Betroffenen kennt, kann der auch einfach so an beliebigem Dom.-Rechner ein falsches Passwort auf den Benutzernamen des betroffenen Kollegen hämmern, bis die Sperre eintritt. Doch auch das würde die Ereignis-ID 4740 anzeigen.
Viele Grüße
von
departure69
Wie verhalt sich das hier:
Seit mehreren Monaten, hat ein Benutzer ein Problem
hierzu?
Ja davon laufen aber diverse Maschinen mit einem Benutzerkonto
Ist das betroffene Konto so eines, oder hat der User ein eigenes auf seinen Namen, das kein anderer mitbenutzt?
Falls er ein eigenes Konto hat, das nur er benutzt:
- kann es sein, daß der beim PWD eintippen so hippelig ist, daß er's jedesmal 3 x mal falsch eintippt, ADHS gibt's auch bei Erwachsenen
- ernsthaft: stell' Dich beim PWD tippen mal neben ihn und sieh' ihm zu, was er macht, viell. ist ein "a" im PW und er erwischt jedesmal die Feststelltaste und bemerkt die Bildschirmmeldung dazu nicht
Im Log auf dem SBS kann ich keinen passenden Eintrag finden...
Welches Log? Hoffentlich meinst Du das Security-Log. Wenn jemand ein falsches PWD bis zur Sperre hämmert, zeigt das die Ereignis-ID 4740 eindeutig an.
Bist Du der einzige Domänen-Admin? Sicher, daß kein normaler Nutzer irgendwann mal das Kennwort eines administrativen Domänenkontos erfahren hat? Jemand, der hier Mobbing gegen den betroffenen Kollegen durch ständige Sabotage betreibt? Und der zufällig, als es mal 1 1/2 Monate keine Probleme gab, im Australien-Urlaub war?
Doch selbst das ist nicht nötig: Wenn ein Kollege den Windows-Benutzernamen des Betroffenen kennt, kann der auch einfach so an beliebigem Dom.-Rechner ein falsches Passwort auf den Benutzernamen des betroffenen Kollegen hämmern, bis die Sperre eintritt. Doch auch das würde die Ereignis-ID 4740 anzeigen.
Viele Grüße
von
departure69
Moin,
wie ist denn das maximales Kennwortalter eingestellt?
Kann es sein, dass er vor kurzem das PW geändert hat und seitdem kommt es zu diesem Verhalten?
Wenn ja, hat er irgendwo sein, nun veraltetes, PW hinterlegt, dass nun sein Konto sperrt.
Kennt er noch sein "altes" PW? Wenn ja, dieses erneut vergeben und dann prüfen ob Ruhe einkehrt.
Dann musst Du nur noch rauskriegen, wo er das hinterlegt hat
BTW: Bei der Nutzeranzahl solltest Du einen Weggang vom SBS in Betracht ziehen, auch bei schmalem Budget
Gruss
wie ist denn das maximales Kennwortalter eingestellt?
Kann es sein, dass er vor kurzem das PW geändert hat und seitdem kommt es zu diesem Verhalten?
Wenn ja, hat er irgendwo sein, nun veraltetes, PW hinterlegt, dass nun sein Konto sperrt.
Kennt er noch sein "altes" PW? Wenn ja, dieses erneut vergeben und dann prüfen ob Ruhe einkehrt.
Dann musst Du nur noch rauskriegen, wo er das hinterlegt hat
BTW: Bei der Nutzeranzahl solltest Du einen Weggang vom SBS in Betracht ziehen, auch bei schmalem Budget
Gruss
Moin noch mal,
"Es ist jedoch nicht erlaubt, die einzeln erhältlichen Lizenzpacks in Geräte- und Benutzerlizenzen aufzusplitten. Sie dürfen also ein 5er-Pack Gerätelizenzen und ein 5er-Pack Benutzerlizenzen kaufen und lizenzieren. Es ist aber nicht erlaubt, dass Sie diese Pakete aufsplitten und zum
Beispiel als 2er-Gerätelizenz und 8er-Benutzerlizenz verwenden.
Wenn Sie mit Geräte-CALs lizenzieren, müssen Sie für jeden PC, der auf diesen Server zugreift, eine Lizenz kaufen, unabhängig davon, wie viele Benutzer an diesem PC arbeiten. Wenn Sie PCs zum Beispiel im Schichtbetrieb betreiben, an denen zu unterschiedlichen Zeiten unterschiedliche Benutzer arbeiten, benötigen Sie für diese PCs nur jeweils eine Geräte-CAL. Im umgekehrten Fall, wenn also ein Benutzer mit mehreren PCs, Notebooks oder Smartphones auf den Server zugreift, benötigen Sie für diesen Benutzer mehrere Geräte-CALs, da dieser Benutzer mit mehreren PCs auf den Server zugreift."
Irgendwie ist mir auch so, als hätte MS eine harte Maximalzahl an zugreifenden clients definiert - bin ich mir aber nicht mehr sicher.
LG, Thomas
Auch wenn ich nicht viel Bugdet für die IT in der Firma habe, dennoch sind wir sauber
wäre ich mir nicht so sicher, ich zitiere mal Herrn Joos:"Es ist jedoch nicht erlaubt, die einzeln erhältlichen Lizenzpacks in Geräte- und Benutzerlizenzen aufzusplitten. Sie dürfen also ein 5er-Pack Gerätelizenzen und ein 5er-Pack Benutzerlizenzen kaufen und lizenzieren. Es ist aber nicht erlaubt, dass Sie diese Pakete aufsplitten und zum
Beispiel als 2er-Gerätelizenz und 8er-Benutzerlizenz verwenden.
Wenn Sie mit Geräte-CALs lizenzieren, müssen Sie für jeden PC, der auf diesen Server zugreift, eine Lizenz kaufen, unabhängig davon, wie viele Benutzer an diesem PC arbeiten. Wenn Sie PCs zum Beispiel im Schichtbetrieb betreiben, an denen zu unterschiedlichen Zeiten unterschiedliche Benutzer arbeiten, benötigen Sie für diese PCs nur jeweils eine Geräte-CAL. Im umgekehrten Fall, wenn also ein Benutzer mit mehreren PCs, Notebooks oder Smartphones auf den Server zugreift, benötigen Sie für diesen Benutzer mehrere Geräte-CALs, da dieser Benutzer mit mehreren PCs auf den Server zugreift."
Irgendwie ist mir auch so, als hätte MS eine harte Maximalzahl an zugreifenden clients definiert - bin ich mir aber nicht mehr sicher.
LG, Thomas
um die Lizenzierung geht es primär nicht. Aber Tipps sind ja immer erlaubt.
Tritt dies bei verschiedenen Rechnern auf?
Hast du mal die Tastatur getauscht? evtl. auch den USB-Port der Tastatur? Batterien bei Funk-Tastatur getauscht? (mal zum Übergang eine kabelgebundene verwenden)
Kann es sein, dass er den NUM-Block benutzt, aber dieser gar nicht aktiv ist?
Wie steht das Tastatur-Layout? US-US, DE-DE, etc.?
Oder der Anwender kann dich einfach nicht ausstehen und will dich ärgern. In dem Moment kann er ja rummeckern und sagen, er kann ja nicht arbeiten, weil er sich nicht anmelden kann. zack, mal eben 15 Minuten nicht am Rechner gearbeitet. Oder der Anwender ist wirklich feinmotorisch nicht gereift.
Tritt dies bei verschiedenen Rechnern auf?
Hast du mal die Tastatur getauscht? evtl. auch den USB-Port der Tastatur? Batterien bei Funk-Tastatur getauscht? (mal zum Übergang eine kabelgebundene verwenden)
Kann es sein, dass er den NUM-Block benutzt, aber dieser gar nicht aktiv ist?
Wie steht das Tastatur-Layout? US-US, DE-DE, etc.?
Oder der Anwender kann dich einfach nicht ausstehen und will dich ärgern. In dem Moment kann er ja rummeckern und sagen, er kann ja nicht arbeiten, weil er sich nicht anmelden kann. zack, mal eben 15 Minuten nicht am Rechner gearbeitet. Oder der Anwender ist wirklich feinmotorisch nicht gereift.
Hi
Bei uns ist meistens auf einem Smartphone eine Synchro mit Exchange eingerichtet, erneuert er das Passwort und trägt das auf dem Phone nicht nach versucht das Tel. immer wieder mit altem Passwort und der Account wird gesperrt.
Einmal hatte ich auch das Phänomen, als ein Client ein anderes Tastaturlayout hatte, als der TS, dass der Benutzer sich nicht mehr anmelden konnte.
Gruss
P.
Bei uns ist meistens auf einem Smartphone eine Synchro mit Exchange eingerichtet, erneuert er das Passwort und trägt das auf dem Phone nicht nach versucht das Tel. immer wieder mit altem Passwort und der Account wird gesperrt.
Einmal hatte ich auch das Phänomen, als ein Client ein anderes Tastaturlayout hatte, als der TS, dass der Benutzer sich nicht mehr anmelden konnte.
Gruss
P.
Moin,
die Problematik deutet darauf hin, daß der Benutzer mehrfach an der Domäne (z. B.: RDP) angemeldet ist und die Session nur getrennt hat, statt sie zu beenden. Aufgrund eines veranlassten oder durchgeführten Passwortwechsels wird das Benutzerkonto gesperrt, da die noch laufende Session das geänderte Passwort wieder zurücksetzt..
Finde heraus, wo der Benutzer überall angemeldet ist und melde ihn ab. Danach ein neues Passwort vergeben, welches der Benutzer ändert, danach sind die Probleme behoben.
Wichtig: Bei Nutzung einer RDP-Sitzung, sollte man sich von diser abmelden und nicht trennen. Leider trennen viele Benutzer die RDP-Session nur, statt sich abzumelden. Wenn man dann den Überblick verliert, wo man sich überall angemeldet hat, bzw. eine RDP-Session gestartet hat ohne diese abzumeldne, tritt dieses Problem auf.
die Problematik deutet darauf hin, daß der Benutzer mehrfach an der Domäne (z. B.: RDP) angemeldet ist und die Session nur getrennt hat, statt sie zu beenden. Aufgrund eines veranlassten oder durchgeführten Passwortwechsels wird das Benutzerkonto gesperrt, da die noch laufende Session das geänderte Passwort wieder zurücksetzt..
Finde heraus, wo der Benutzer überall angemeldet ist und melde ihn ab. Danach ein neues Passwort vergeben, welches der Benutzer ändert, danach sind die Probleme behoben.
Wichtig: Bei Nutzung einer RDP-Sitzung, sollte man sich von diser abmelden und nicht trennen. Leider trennen viele Benutzer die RDP-Session nur, statt sich abzumelden. Wenn man dann den Überblick verliert, wo man sich überall angemeldet hat, bzw. eine RDP-Session gestartet hat ohne diese abzumeldne, tritt dieses Problem auf.
Hi
man kann nur raten woran es liegt. In den Logs (Eventlogs \ Securirty) schauen und suche nach der Eventlog ID 4625 (https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.a ..) da steht dann auch das Gerät was dafür verantwortlich ist und du kannst da gezielt rangehen.
Optional: Besorge dir einen Syslogserver (syslog-ng, rsyslog, graysyslog) und lass die Logs des Anmeldeserver dorthin laufen, das erleichtert die Suche nach dem Fehler.
Gruß
@clSchak
man kann nur raten woran es liegt. In den Logs (Eventlogs \ Securirty) schauen und suche nach der Eventlog ID 4625 (https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.a ..) da steht dann auch das Gerät was dafür verantwortlich ist und du kannst da gezielt rangehen.
Optional: Besorge dir einen Syslogserver (syslog-ng, rsyslog, graysyslog) und lass die Logs des Anmeldeserver dorthin laufen, das erleichtert die Suche nach dem Fehler.
Gruß
@clSchak
Mahlzeit,
Dafuer gibt es doch diese netten Einstellungen per GPO, dass getrennte Sitzungen nach Ablauf einer gewissen Zeit beendet werden.
BFF
sollte man sich von diser abmelden und nicht trennen. Leider trennen viele Benutzer die RDP-Session nur, statt sich abzumelden. Wenn man dann den Überblick verliert, wo man sich überall angemeldet hat, bzw. eine RDP-Session gestartet hat ohne diese abzumeldne, tritt dieses Problem auf.
Dafuer gibt es doch diese netten Einstellungen per GPO, dass getrennte Sitzungen nach Ablauf einer gewissen Zeit beendet werden.
BFF
@Kirdy1301:
Vermutlich durch Umbenennen undsoweiter?
Hab' ich früher auch so gemacht (z. B. bei Namensänderung durch Eheschließung o. ä.), hat aber immer wieder Schwierigkeiten bereitet.
Wenn's nicht zuviel Aufwand ist, leg' den betroffenen User doch mal ganz frisch an, so, als hätte es ihn noch nie gegeben. Vorher Backup seiner Daten und Einstellungen, dürfte klar sein.
Zu Deinen beiden Screenshots:
Gilt für den betroffenen User nun der erste oder der zweite? In Deiner Ursprungsfrage schreibst Du noch, das dort sehr wohl
Jedoch egal wie, wenn er gesperrt ist, muß das einen Grund haben.
Ich tippe nach wie vor darauf, daß jemand anderer ihm böse Streiche spielt, wie das geht, habe ich oben beschrieben. Irgendjemand hämmert auf seinen Anmeldenamen x-fach ein beliebiges, falsches PWD und erreicht so, daß er gesperrt ist.
Viele Grüße
von
departure69
Das kuriose ist ja das ich dem User ein aus einem bestehenden Account (Tester12345) seinen neuen Useraccount umgestrickt habe
Vermutlich durch Umbenennen undsoweiter?
Hab' ich früher auch so gemacht (z. B. bei Namensänderung durch Eheschließung o. ä.), hat aber immer wieder Schwierigkeiten bereitet.
Wenn's nicht zuviel Aufwand ist, leg' den betroffenen User doch mal ganz frisch an, so, als hätte es ihn noch nie gegeben. Vorher Backup seiner Daten und Einstellungen, dürfte klar sein.
Zu Deinen beiden Screenshots:
Gilt für den betroffenen User nun der erste oder der zweite? In Deiner Ursprungsfrage schreibst Du noch, das dort sehr wohl
"Heben Sie die Kontosperrung auf, Das Konto ist derzeit auf dem Active-Directory-Domänencontroller gesperrt".
steht, was denn nun?Jedoch egal wie, wenn er gesperrt ist, muß das einen Grund haben.
Ich tippe nach wie vor darauf, daß jemand anderer ihm böse Streiche spielt, wie das geht, habe ich oben beschrieben. Irgendjemand hämmert auf seinen Anmeldenamen x-fach ein beliebiges, falsches PWD und erreicht so, daß er gesperrt ist.
Viele Grüße
von
departure69
Hast Du meinen Beitrag gelesen und verstanden?
Versuche herauszufinden wo der Benutzer aktive oder inaktive Sessions hat, wo NUR getrennt sind.
hast Du diese gefunden, dann trenne Sie.
Und schau bei allen Servern/Workstations nach, wo man mittels RDP/VNC whatsoever eine Verbindung bei Euch öffnen kann.
Gruss Penny
Versuche herauszufinden wo der Benutzer aktive oder inaktive Sessions hat, wo NUR getrennt sind.
hast Du diese gefunden, dann trenne Sie.
Und schau bei allen Servern/Workstations nach, wo man mittels RDP/VNC whatsoever eine Verbindung bei Euch öffnen kann.
Gruss Penny
Mahlzeit,
ich vermute, dass in irgendeiner Software (oder ein Dienst) auf eine Freigabe mit hinterlegten Credentials zugegriffen wird. Das Passwort stimmt nicht mehr und deshalb die Kontosperrung.
Das bestärkt mich in meiner Annahme:
Jetzt ist es an dir, herauszufinden, von welchem Gerät das kommt (Logs des DC sollten helfen).
ich vermute, dass in irgendeiner Software (oder ein Dienst) auf eine Freigabe mit hinterlegten Credentials zugegriffen wird. Das Passwort stimmt nicht mehr und deshalb die Kontosperrung.
Das bestärkt mich in meiner Annahme:
Das kuriose ist ja das ich dem User ein aus einem bestehenden Account (Tester12345) sein neuen Useraccount umgestrickt habe, Exchange
Jetzt ist es an dir, herauszufinden, von welchem Gerät das kommt (Logs des DC sollten helfen).
Hi
ganz doofe Idee am Rande: hat der User evtl. sein Postfach auf seinem Smartphone eingerichtet?
Dann wurde das Kennwort geändert am PC, aber im Smartphone vergessen ebenfalls das neue Kennwort zu setzen?
So sperren sich jedenfalls meine Pappenheimer immer aus..., weil sich dann das Smartphone immer mit falschem Benutzerkennwort anmelden will.
Gruss
Tom
ganz doofe Idee am Rande: hat der User evtl. sein Postfach auf seinem Smartphone eingerichtet?
Dann wurde das Kennwort geändert am PC, aber im Smartphone vergessen ebenfalls das neue Kennwort zu setzen?
So sperren sich jedenfalls meine Pappenheimer immer aus..., weil sich dann das Smartphone immer mit falschem Benutzerkennwort anmelden will.
Gruss
Tom
Zitat von @Kirdy1301:
@Penny.Cilin
ja deinen Beitrag habe ich gelesen und verstanden, danke für die Idee.
Der Benutzer könnte sich nur alternativ am Terminalserver anmelden, dort habe ich schon geschaut, ob er dort noch angemeldet ist, habe ihn auch gefragt, ob er an einem "fremden" Arbeitsplatz gearbeitet hat. - Auch nein.
Gruß Kirdy1301
OK, dann bleibt der vorherige Beitrag von thaefliger@Penny.Cilin
ja deinen Beitrag habe ich gelesen und verstanden, danke für die Idee.
Benutzer mehrfach an der Domäne (z. B.: RDP) angemeldet
Der Benutzer könnte sich nur alternativ am Terminalserver anmelden, dort habe ich schon geschaut, ob er dort noch angemeldet ist, habe ihn auch gefragt, ob er an einem "fremden" Arbeitsplatz gearbeitet hat. - Auch nein.
Gruß Kirdy1301
- Smartphone
- Tablet
- oder anderes Device (evtl. Laufwerksverbindung auf einer Freigabe)
Das kein Eventlog Eintrag existiert auf dem die Falscheingabe des Passwortes zurück zu führen ist kann nicht sein, dass ist unmöglich. Du musst alle DC's durchsehen und nicht nur einen, die Eventlogs werden nicht synchronisiert, am einfachsten via simplen Logserver.
Dann siehst auch welches Device dafür verantwortlich ist.
Dann siehst auch welches Device dafür verantwortlich ist.