(mal wieder) Client im AD sperrt sich
Hallo liebe Kollegen und Koleginnen,
wir haben seit geraumer Zeit das Problem, dass sich ein einzelner Windows 7 Client in unserem Active Directory (2008 R2) ein Client mehrmals am Tag random sperrt. Der Fehler ist nicht reproduzierbar - der User verlässt seinen Platz, sperrt den Rechner und wenn er sein Passwort eingiebt stehten die Chancen gut, dass das Konto gesperrt ist und von uns entsperrt werden muss. Gesperrt wird er übrigens auch immer zuerst an dem DC, an dessen Standort sich auch der Client befindet (haben mehrere DCs an mehreren Standorten).
Bevor hier jetzt gleich mehrere Antworten mit "das Thema hatten wir hier schon" kommen: Nein, der Client wurde nicht mit einem Image eines anderen Clients aufgesetzt und nein, wenn sich die Kiste sperrt ist der User nirgens sonst mit seinem Konto eingeloggt (also z.B. ein Terminalserver oder ähnliches).
Beim Troubleshooting haben wir z.B. schon versucht, den Client vollständig aus der Domäne zu entfernen und wieder rein zu heben. Außerdem habe ich am Client und am DC das Eventlog gecheckt. Beides ohne Erfolg.
Ich habe zwei Verdächte (schreibt man das so?) bei denen ich aber nicht genau weiß, wie ich ihnen weiter nachgehen kann:
1. Eingehende Recherche (sprich Befragung der halben Belegschaft) hat ergeben, dass das AD Konto warum auch immer (bitte fragt nicht) wohl gelöscht und anschließend neu angelegt wurde. Laut dem löchrigen Erinnerungsvermögen besagter Kollegen war das bevor die Problematik das erste mal auftauchte. Mein Verdacht: Gibt es evtl. eine Art interne ID, welche mit jedem Konto verknüpft ist und welche nach dem löschen des Kontos weiter geführt wird? Evtl. verschluckt sich die Domäne, da kurz darauf ein neues Konto mit gleichen Namen angelegt wurde.
2. Wir benutzen intern ein selbstgehostetes Ticket-System namens JIRA (Beileidsbekundungen bitte per PN). Jeder User hat ein JIRA-Konto, welches sich seine Anmeldeinformationen aus dem AD holt. Etwa zeitgleich mit der AD-Problemati hat das JIRA-Konto des Users angefangen, sich ebenfalls random zu sperren (Anzahl der fehlgeschlagenen Logins zu hoch - muss zurückgesetzt werden). Das verrückte ist aber, dass zwar beide Probleme etwa zeitgleich anfingen, aber die beiden Konten niemals gleichzeitig gesperrt sind. Hier haben wir schon diverse Browser versucht, Cache/Cookies löschen usw.
Vielleicht hat ja jemand eine gute Idee, wie ich diese beiden Theorien weiter verfolgen kann. Vlt. fällt auch jemandem ein weiterer Lösungsansatz ein. Ich bin jedenfalls für jeden Denkanstoß dankbar.
Beste Grüße, freenode.
wir haben seit geraumer Zeit das Problem, dass sich ein einzelner Windows 7 Client in unserem Active Directory (2008 R2) ein Client mehrmals am Tag random sperrt. Der Fehler ist nicht reproduzierbar - der User verlässt seinen Platz, sperrt den Rechner und wenn er sein Passwort eingiebt stehten die Chancen gut, dass das Konto gesperrt ist und von uns entsperrt werden muss. Gesperrt wird er übrigens auch immer zuerst an dem DC, an dessen Standort sich auch der Client befindet (haben mehrere DCs an mehreren Standorten).
Bevor hier jetzt gleich mehrere Antworten mit "das Thema hatten wir hier schon" kommen: Nein, der Client wurde nicht mit einem Image eines anderen Clients aufgesetzt und nein, wenn sich die Kiste sperrt ist der User nirgens sonst mit seinem Konto eingeloggt (also z.B. ein Terminalserver oder ähnliches).
Beim Troubleshooting haben wir z.B. schon versucht, den Client vollständig aus der Domäne zu entfernen und wieder rein zu heben. Außerdem habe ich am Client und am DC das Eventlog gecheckt. Beides ohne Erfolg.
Ich habe zwei Verdächte (schreibt man das so?) bei denen ich aber nicht genau weiß, wie ich ihnen weiter nachgehen kann:
1. Eingehende Recherche (sprich Befragung der halben Belegschaft) hat ergeben, dass das AD Konto warum auch immer (bitte fragt nicht) wohl gelöscht und anschließend neu angelegt wurde. Laut dem löchrigen Erinnerungsvermögen besagter Kollegen war das bevor die Problematik das erste mal auftauchte. Mein Verdacht: Gibt es evtl. eine Art interne ID, welche mit jedem Konto verknüpft ist und welche nach dem löschen des Kontos weiter geführt wird? Evtl. verschluckt sich die Domäne, da kurz darauf ein neues Konto mit gleichen Namen angelegt wurde.
2. Wir benutzen intern ein selbstgehostetes Ticket-System namens JIRA (Beileidsbekundungen bitte per PN). Jeder User hat ein JIRA-Konto, welches sich seine Anmeldeinformationen aus dem AD holt. Etwa zeitgleich mit der AD-Problemati hat das JIRA-Konto des Users angefangen, sich ebenfalls random zu sperren (Anzahl der fehlgeschlagenen Logins zu hoch - muss zurückgesetzt werden). Das verrückte ist aber, dass zwar beide Probleme etwa zeitgleich anfingen, aber die beiden Konten niemals gleichzeitig gesperrt sind. Hier haben wir schon diverse Browser versucht, Cache/Cookies löschen usw.
Vielleicht hat ja jemand eine gute Idee, wie ich diese beiden Theorien weiter verfolgen kann. Vlt. fällt auch jemandem ein weiterer Lösungsansatz ein. Ich bin jedenfalls für jeden Denkanstoß dankbar.
Beste Grüße, freenode.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 281634
Url: https://administrator.de/contentid/281634
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
27 Kommentare
Neuester Kommentar
Hi,
"Verdachte" wäre richtig.
Das Neuanlegen des Kontos mit gleichem Namen wird nicht zum "Verschlucken" der Domäne führen. Das Konto hat dann eine andere SID, aber das hat erstmal nichts in dieser Richtung eine Bewandnis.
Du hast ja schon ne Menge ausgeschlossen. Da bleibt doch bloß noch Faktor Mensch, oder? Irgendwer versucht absichtlich oder unabsichtlich den Desktop zu entsperren oder sich am JIRA anzumelden, kennt das Passwort aber nicht, versucht es und das Konto wird gesperrt.
Du könntest am besagten PC mal die Aufzeichnung der Anmeldeversuche aktivieren. Diese würden dann ins Eventlog "Sicherheit" geschrieben. Vielleicht tauchen da ja dann einige "fehlgschlagen" auf. Gleiches kannst Du in der Domäne aktivieren. Das wird dann auf den DC's gelogt. Aber Vorsicht: Hier muss man dann ne Menge konfigurieren, da das Sicherheitslog auf einem DC standardmäßig sehr viele Einträge erhält. Also entweder die Überwachung dann einschränken oder die relevanten Events mittels Eventlog Collector gefiltert an einen anderen Server weiterleiten.
E.
"Verdachte" wäre richtig.
Das Neuanlegen des Kontos mit gleichem Namen wird nicht zum "Verschlucken" der Domäne führen. Das Konto hat dann eine andere SID, aber das hat erstmal nichts in dieser Richtung eine Bewandnis.
Du hast ja schon ne Menge ausgeschlossen. Da bleibt doch bloß noch Faktor Mensch, oder? Irgendwer versucht absichtlich oder unabsichtlich den Desktop zu entsperren oder sich am JIRA anzumelden, kennt das Passwort aber nicht, versucht es und das Konto wird gesperrt.
Du könntest am besagten PC mal die Aufzeichnung der Anmeldeversuche aktivieren. Diese würden dann ins Eventlog "Sicherheit" geschrieben. Vielleicht tauchen da ja dann einige "fehlgschlagen" auf. Gleiches kannst Du in der Domäne aktivieren. Das wird dann auf den DC's gelogt. Aber Vorsicht: Hier muss man dann ne Menge konfigurieren, da das Sicherheitslog auf einem DC standardmäßig sehr viele Einträge erhält. Also entweder die Überwachung dann einschränken oder die relevanten Events mittels Eventlog Collector gefiltert an einen anderen Server weiterleiten.
E.
Hallo,
Benutzer löschen und mit gleichem Namen anlegen ist immer eine blöde Idee.
Das AD arbeitet intern mit SID (IDs) wenn ein Objekt gelöscht wird zack ist die ID wieder frei.
Diese ID ist auch noch in allen ACL hinterlegt und sollte irgendwann mal ein neuer Benutzer die alte ID bekommen hat der auch die Zugriffe wie diese alte ID .
Der Benutzewr mit dem gleichen Namen, hat aber eine andere ID.
Hat der Benutzer im Browser sein Jira Passwort gespeichert? Oder ist das Jira soweit eingebunden das es mit Singel Sign On vom AD funktioniert?
Jirapasswort aus dem Browser löschen, wenn vorhanden, das speichern erstmal verbieten und dem AD-Benutzer ein neues Passwort geben.
Auf dem DC mal nach Sicherheits Events: 4625 suchen.
Wenn ein Exchange da ist dort auch, nicht das da noch ein altes Passwort rumgeistert.
Wenn Der Benutzer gesperrt wird, warum hast Du das Computerkonto in Verdacht?
Gruß
Chonta
Benutzer löschen und mit gleichem Namen anlegen ist immer eine blöde Idee.
Das AD arbeitet intern mit SID (IDs) wenn ein Objekt gelöscht wird zack ist die ID wieder frei.
Diese ID ist auch noch in allen ACL hinterlegt und sollte irgendwann mal ein neuer Benutzer die alte ID bekommen hat der auch die Zugriffe wie diese alte ID .
Der Benutzewr mit dem gleichen Namen, hat aber eine andere ID.
Hat der Benutzer im Browser sein Jira Passwort gespeichert? Oder ist das Jira soweit eingebunden das es mit Singel Sign On vom AD funktioniert?
Jirapasswort aus dem Browser löschen, wenn vorhanden, das speichern erstmal verbieten und dem AD-Benutzer ein neues Passwort geben.
Auf dem DC mal nach Sicherheits Events: 4625 suchen.
Wenn ein Exchange da ist dort auch, nicht das da noch ein altes Passwort rumgeistert.
Wenn Der Benutzer gesperrt wird, warum hast Du das Computerkonto in Verdacht?
Gruß
Chonta
Hallo freenode,
angelegte User bekommen im AD eine eigene ID, das ist die S-xxxx-usw., die manchmal in den Berechtigungen drin steht, wenn ein geläschter User eine explizite Berechtigung auf das Filessysem hatte. Ob der Username früher schon mal vorhanden war, ist egal, es wird eine neue SID erzeugt.
Und da ich hätte tatsächlich eine Theorie:
Kann es sein, dass der User mit dem zwischendurch mal gelöschten Konto schon vorher an dem Client angemeldet war? Ist das Profil des "alten" Users auf dem Client inn dem Zusammenhang auch gelöscht worden? Oder arbeitet der User vielleicht immernoch mit den "alten" Profil? In dem Fall könnten die SIDs sich ins Gehege kommen. Ist aber wirklich nur so eine Idee...
geTuemII
angelegte User bekommen im AD eine eigene ID, das ist die S-xxxx-usw., die manchmal in den Berechtigungen drin steht, wenn ein geläschter User eine explizite Berechtigung auf das Filessysem hatte. Ob der Username früher schon mal vorhanden war, ist egal, es wird eine neue SID erzeugt.
Und da ich hätte tatsächlich eine Theorie:
Kann es sein, dass der User mit dem zwischendurch mal gelöschten Konto schon vorher an dem Client angemeldet war? Ist das Profil des "alten" Users auf dem Client inn dem Zusammenhang auch gelöscht worden? Oder arbeitet der User vielleicht immernoch mit den "alten" Profil? In dem Fall könnten die SIDs sich ins Gehege kommen. Ist aber wirklich nur so eine Idee...
geTuemII
Das kann man glaube ich ausschließen. Denn der Client ist direkt nach dem ersten Anmeldeversuch gesperrt. Der User gibt sein
Passwort aber richtig ein - nach dem entsperren des Kontos geht es ja wieder.
Und wir haben ihm zu Testzwecken auch schon ein extrem simples Kennwort gegeben. ;)
Du hast mich mißverstanden. Ich rede von anderen Personen, die das versuchen könnten. Solche, die das Passwort gar nicht kennen könnten und dürfen.Passwort aber richtig ein - nach dem entsperren des Kontos geht es ja wieder.
Und wir haben ihm zu Testzwecken auch schon ein extrem simples Kennwort gegeben. ;)
E.
Nein, nicht direkt mit dem Profilordner, aber mit dem Userprofil auf dem Client, das evtl. noch die alte SID verwendet.
Was passiert eigentlich, wenn der betroffene User sich an einem anderen Client anmeldet? Und was, wenn sich ein anderer User am betroffenen Cleint anmeldet? Wenn beides funktioniert, liegt das Problem in der Kombi spezieller User an bestimmten Client.
Das würde dann für meine Theorie sprechen...
geTuemII
Was passiert eigentlich, wenn der betroffene User sich an einem anderen Client anmeldet? Und was, wenn sich ein anderer User am betroffenen Cleint anmeldet? Wenn beides funktioniert, liegt das Problem in der Kombi spezieller User an bestimmten Client.
Das würde dann für meine Theorie sprechen...
geTuemII
Nein, nicht direkt mit dem Profilordner, aber mit dem Userprofil auf dem Client, das evtl. noch die alte SID verwendet.
Das halte ich für ausgeschlossen.- Selbst wenn es so wäre: Was soll das ändern? Benutzer meldet sich an, sperrt den Desktop und kann ihn dann nicht mehr entsperren, weil das Konto gesperrt ist. Wo soll da ein "falsches" Profil zum Tragen kommen?
- Merkt Windows beim Anmelden eines Benutzers, wenn da bereits ein gleichnamiger Profilordner existiert, welches seines Wissens nicht zu diesem User gehört und erstellt dann automatisch einen im Namen variierten Ordner. Also "UserA" meldet sich an. Odner "UserA" gibt es schon. Registry sagt: Gehört ihm nicht. Windows erstellt "UserA.001" o.ä.
E.
Wie ich bereits sagte: es handelt sich um eine Theorie...
@emeriks: Der TO hat schon Einiges ausgeschlossen. In solchen Fällen habe ich die Erfahrung gemacht, dass oft Querdenken hilft.
Meinjanur,
geTuemII
@emeriks: Der TO hat schon Einiges ausgeschlossen. In solchen Fällen habe ich die Erfahrung gemacht, dass oft Querdenken hilft.
Meinjanur,
geTuemII
Zitat von @freenode:
Gesperrt wird er übrigens auch immer zuerst an dem DC, an dessen Standort sich auch der Client befindet
Soll das so nicht sein? Der Lokale DC am Standort ist doch zu 99,99 % immer der Logonserver, oder nicht?Gesperrt wird er übrigens auch immer zuerst an dem DC, an dessen Standort sich auch der Client befindet
eingeloggt (also z.B. ein Terminalserver oder ähnliches).
WLAN ist vorhanden und nutzbar (Kein Gäste netz oder so)?Außerdem habe ich am Client und am DC das Eventlog gecheckt. Beides ohne Erfolg.
Im Ereignisprotokoll vom DC wo das Benutzerkonto gesperrt ist steht nichts dazu drin? Auch keine Anmeldungen vom Client oder Benutzer?Passiert das Sperren auch wenn der Client ohne LAN testweise gestartet und genutzt bzw. Manuell gesperrt wird usw.?
Gruß,
Peter
schau mal hier, vielleicht hilft das:
https://support.microsoft.com/en-us/kb/824209
Wenn ein Domänenkonto gesperrt wird, erfolgt immer ein Eintrag im Sicherheitslog des korrespondierenden DC's.
Um das Problem einzukreisen, würde ich den Problemrechner mal ausschalten und den betroffenen Anwender von einem anderen (am besten jungfräulichen) Client arbeiten lassen.
Gruß
Torsten
https://support.microsoft.com/en-us/kb/824209
Wenn ein Domänenkonto gesperrt wird, erfolgt immer ein Eintrag im Sicherheitslog des korrespondierenden DC's.
Um das Problem einzukreisen, würde ich den Problemrechner mal ausschalten und den betroffenen Anwender von einem anderen (am besten jungfräulichen) Client arbeiten lassen.
Gruß
Torsten
Hi,
ich würde auch die Security Logs am betroffenen DC durchsuchen und vermute ein Passwort Wechsel des Benutzers. Ich konnte durch folgende Vorgehensweise 2 ähnliche Probleme lösen.
1.) Filtere am DC im Security Eventlog nach Keyword: Audit Failure
Danach den Zeitraum des Login Versuches durchsuchen. Mit etwas Glück findet man in diesem Zeitraum dabei einen Eintrag und in den Details die
Danach muss man sich den auslösenden Client/Server noch mal im Detail ansehen - Leider gibt es hier keine Standardvorgehensweise. Hängt davon ab, was am auslösenden Computer installiert ist.
2.) Filter am DC im Security Eventlog nach der EventID 4740: User Account Management - A user account was locked out
Im Text findet sich dazu der
Im 2. Fall war es bei mir der RADIUS Server. In den RADIUS Logs kam ich dann auf das Handy des betroffenen Benutzers. Beim Handy das hinterlegte Passwort des Benutzers aktualisiert und das Problem war gelöst.
Viele Grüße
SeriousEE
ich würde auch die Security Logs am betroffenen DC durchsuchen und vermute ein Passwort Wechsel des Benutzers. Ich konnte durch folgende Vorgehensweise 2 ähnliche Probleme lösen.
1.) Filtere am DC im Security Eventlog nach Keyword: Audit Failure
Danach den Zeitraum des Login Versuches durchsuchen. Mit etwas Glück findet man in diesem Zeitraum dabei einen Eintrag und in den Details die
Source Network Address
. Damit bekommst du den auslösenden Client/Server, welcher nicht zwingend der Client-Rechner sein muss an dem der User gerade das Passwort eintippt!Danach muss man sich den auslösenden Client/Server noch mal im Detail ansehen - Leider gibt es hier keine Standardvorgehensweise. Hängt davon ab, was am auslösenden Computer installiert ist.
2.) Filter am DC im Security Eventlog nach der EventID 4740: User Account Management - A user account was locked out
Im Text findet sich dazu der
Caller Computer Name
und damit wieder der auslösende Client/ServerIm 2. Fall war es bei mir der RADIUS Server. In den RADIUS Logs kam ich dann auf das Handy des betroffenen Benutzers. Beim Handy das hinterlegte Passwort des Benutzers aktualisiert und das Problem war gelöst.
Viele Grüße
SeriousEE
sag ich doch > Zitat von @freenode:
Punkt 2 war die Lösung. Danke an alle!
Zitat von @SeriousEE:
Hi,
ich würde auch die Security Logs am betroffenen DC durchsuchen und vermute ein Passwort Wechsel des Benutzers. Ich konnte durch folgende Vorgehensweise 2 ähnliche Probleme lösen.
1.) Filtere am DC im Security Eventlog nach Keyword: Audit Failure
Danach den Zeitraum des Login Versuches durchsuchen. Mit etwas Glück findet man in diesem Zeitraum dabei einen Eintrag und in den Details die
Danach muss man sich den auslösenden Client/Server noch mal im Detail ansehen - Leider gibt es hier keine Standardvorgehensweise. Hängt davon ab, was am auslösenden Computer installiert ist.
2.) Filter am DC im Security Eventlog nach der EventID 4740: User Account Management - A user account was locked out
Im Text findet sich dazu der
Im 2. Fall war es bei mir der RADIUS Server. In den RADIUS Logs kam ich dann auf das Handy des betroffenen Benutzers. Beim Handy das hinterlegte Passwort des Benutzers aktualisiert und das Problem war gelöst.
Viele Grüße
SeriousEE
Hi,
ich würde auch die Security Logs am betroffenen DC durchsuchen und vermute ein Passwort Wechsel des Benutzers. Ich konnte durch folgende Vorgehensweise 2 ähnliche Probleme lösen.
1.) Filtere am DC im Security Eventlog nach Keyword: Audit Failure
Danach den Zeitraum des Login Versuches durchsuchen. Mit etwas Glück findet man in diesem Zeitraum dabei einen Eintrag und in den Details die
Source Network Address
. Damit bekommst du den auslösenden Client/Server, welcher nicht zwingend der Client-Rechner sein muss an dem der User gerade das Passwort eintippt!Danach muss man sich den auslösenden Client/Server noch mal im Detail ansehen - Leider gibt es hier keine Standardvorgehensweise. Hängt davon ab, was am auslösenden Computer installiert ist.
2.) Filter am DC im Security Eventlog nach der EventID 4740: User Account Management - A user account was locked out
Im Text findet sich dazu der
Caller Computer Name
und damit wieder der auslösende Client/ServerIm 2. Fall war es bei mir der RADIUS Server. In den RADIUS Logs kam ich dann auf das Handy des betroffenen Benutzers. Beim Handy das hinterlegte Passwort des Benutzers aktualisiert und das Problem war gelöst.
Viele Grüße
SeriousEE
Punkt 2 war die Lösung. Danke an alle!