27
(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.
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: 281634
Url: https://administrator.de/forum/mal-wieder-client-im-ad-sperrt-sich-281634.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
27 Kommentare
Neuester Kommentar
Moin freenode,
habt ihr den Benutzer schon mal komplett gelöscht?
Also von jedem DC und aus allen Einträgen wo dieser drin steht und neu eingefügt.
Vielleicht liegt ja noch iwo ein Relikt dieses Users was so ein wenig rumspinnt.
Gruß
teggers
habt ihr den Benutzer schon mal komplett gelöscht?
Also von jedem DC und aus allen Einträgen wo dieser drin steht und neu eingefügt.
Vielleicht liegt ja noch iwo ein Relikt dieses Users was so ein wenig rumspinnt.
Gruß
teggers
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
Das AD arbeitet intern mit SID (IDs) wenn ein Objekt gelöscht wird zack ist die ID wieder frei.
Sorry, aber das ist Quatsch. Die RID wird innerhalb einer Domäne stetig hochgezählt. Diese hat zwar sicher eine obere Grenze, aber diese dürfte sehr hoch sein.E.
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
Moin.
Hat besagter Client einen Fingerprint-Reader und falls ja, wurde der konfiguriert/benutzt?
Wir hatten hier ein "wildgewordenes" ThinkPad, bei dem erst das Löschen der gespeicherten Fingerprints im BIOS das Problem gelöst hat.
Cheers,
jsysde
Hat besagter Client einen Fingerprint-Reader und falls ja, wurde der konfiguriert/benutzt?
Wir hatten hier ein "wildgewordenes" ThinkPad, bei dem erst das Löschen der gespeicherten Fingerprints im BIOS das Problem gelöst hat.
Cheers,
jsysde
Ok, hab mich eben nochmal eingelesen, Du hast Recht.
Gelöscht ist gelöscht.
Hatte das mal anders gelernt...
Gruß
Chonta
Gelöscht ist gelöscht.
Hatte das mal anders gelernt...
Gruß
Chonta
Zitat von @emeriks:
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 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.
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. ;)
Zitat von @geTuemII:
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...
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...
Ja, der User saß vorher am selben Client.
Hängt das evtl. mit dem Profilordner zusammen?
Zitat von @jsysde:
Hat besagter Client einen Fingerprint-Reader und falls ja, wurde der konfiguriert/benutzt?
Wir hatten hier ein "wildgewordenes" ThinkPad, bei dem erst das Löschen der gespeicherten Fingerprints im BIOS das
Problem gelöst hat.
Hat besagter Client einen Fingerprint-Reader und falls ja, wurde der konfiguriert/benutzt?
Wir hatten hier ein "wildgewordenes" ThinkPad, bei dem erst das Löschen der gespeicherten Fingerprints im BIOS das
Problem gelöst hat.
Leider nein, aber danke für die Idee.
Hat zwar einen Reader, der wird aber nicht benutzt und ist deaktiviert.
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
Kann es sein dass der User vor kurzen sein Kennwort ändern musste?
Falls er ActiveSync oder ähnliches hat könnte dies den Account sperren....(quasi neues Kennwort auf einem Smartphone o.ä nicht geändert, versucht dann ständig sich zu authentifizieren).
Falls er ActiveSync oder ähnliches hat könnte dies den Account sperren....(quasi neues Kennwort auf einem Smartphone o.ä nicht geändert, versucht dann ständig sich zu authentifizieren).
Zitat von @Pjordorf:
> 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?
> 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
> 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?
> 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
Ja klar soll das so sein - ich dachte mir nur ich erwähns mal.
Es gibt ein Gäste-WLAN, der Client ist allerdings fest per Kabel im Netz.
Den vorschlag ohne LAN zu booten werde ich mal ausprobieren.
Zitat von @Dr.Cornwallis:
Kann es sein dass der User vor kurzen sein Kennwort ändern musste?
Falls er ActiveSync oder ähnliches hat könnte dies den Account sperren....(quasi neues Kennwort auf einem Smartphone
o.ä nicht geändert, versucht dann ständig sich zu authentifizieren).
Kann es sein dass der User vor kurzen sein Kennwort ändern musste?
Falls er ActiveSync oder ähnliches hat könnte dies den Account sperren....(quasi neues Kennwort auf einem Smartphone
o.ä nicht geändert, versucht dann ständig sich zu authentifizieren).
Das kann sein, da wir Smartphones für Email- und Terminsynchronisation verwenden.
Du kannst es überprüfen in dem du folgendes cmdlet eingibst:
net user %username% /Domain -> Username natürlich eingeben
dann siehst du wann das Kennwort das letzte mal geändert wurde.
Greets
net user %username% /Domain -> Username natürlich eingeben
dann siehst du wann das Kennwort das letzte mal geändert wurde.
Greets
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
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
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
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 derClient-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
Hi, mal ne blöde Frage: In welchem Protokoll vom Eventlog suchst Du denn da? Ganz normal im System?
Sicherheit
Hallo,
Sicherheit?
Gruß
Chonta
Hi, mal ne blöde Frage: In welchem Protokoll vom Eventlog suchst Du denn da? Ganz normal im System?
Sicherheit?
Gruß
Chonta
Zitat von @SeriousEE:
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.
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.
Okay, habe jetzt das richtige Protokoll genommen und nach Deiner Methode interessanterweise einen unserer Server als Aufrufcomputer ausfindig gemacht (alleine heute Vormittag 3x gesperrt). Interessanterweise war der User auf diesem getrennt, aber angemeldet - obwohl er seit 2 Tagen im Urlaub ist. Ich habe ihn jetzt mal abgemeldet und beobachte weiter.
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!
sag ich doch > Zitat von @freenode:
Punkt 2 war die Lösung. Danke an alle!
> Zitat von @freenode: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!
