freenode
Goto Top

(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. face-smile

Beste Grüße, freenode.

Content-Key: 281634

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

Printed on: April 23, 2024 at 17:04 o'clock

Member: teggers
teggers Aug 31, 2015 at 13:04:53 (UTC)
Goto Top
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
Member: emeriks
emeriks Aug 31, 2015 updated at 13:08:03 (UTC)
Goto Top
Hi,
"Verdachte" wäre richtig. face-wink

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.
Member: Chonta
Chonta Aug 31, 2015 at 13:07:33 (UTC)
Goto Top
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 face-smile.
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
Member: emeriks
emeriks Aug 31, 2015 at 13:09:28 (UTC)
Goto Top
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.
Member: geTuemII
geTuemII Aug 31, 2015 at 13:14:00 (UTC)
Goto Top
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
Member: jsysde
jsysde Aug 31, 2015 at 13:14:01 (UTC)
Goto Top
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
Member: Chonta
Chonta Aug 31, 2015 at 13:17:10 (UTC)
Goto Top
Ok, hab mich eben nochmal eingelesen, Du hast Recht.
Gelöscht ist gelöscht.
Hatte das mal anders gelernt...

Gruß

Chonta
Member: freenode
freenode Aug 31, 2015 at 13:26:23 (UTC)
Goto Top
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.

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. ;)
Member: freenode
freenode Aug 31, 2015 at 13:28:05 (UTC)
Goto Top
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...

Ja, der User saß vorher am selben Client.
Hängt das evtl. mit dem Profilordner zusammen?
Member: freenode
freenode Aug 31, 2015 at 13:28:49 (UTC)
Goto Top
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.

Leider nein, aber danke für die Idee. face-smile
Hat zwar einen Reader, der wird aber nicht benutzt und ist deaktiviert.
Member: emeriks
emeriks Aug 31, 2015 at 13:36:23 (UTC)
Goto Top
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.

E.
Member: geTuemII
geTuemII Aug 31, 2015 at 13:48:47 (UTC)
Goto Top
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
Member: emeriks
emeriks Aug 31, 2015 updated at 13:54:00 (UTC)
Goto Top
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.

  1. 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?
  2. 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.
Member: geTuemII
geTuemII Aug 31, 2015 at 14:09:09 (UTC)
Goto Top
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
Member: Pjordorf
Pjordorf Aug 31, 2015 updated at 14:34:49 (UTC)
Goto Top
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
Member: Dr.Cornwallis
Dr.Cornwallis Sep 01, 2015 at 09:14:11 (UTC)
Goto Top
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).
Member: freenode
freenode Sep 01, 2015 at 09:48:46 (UTC)
Goto Top
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


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.
Member: freenode
freenode Sep 01, 2015 at 09:49:49 (UTC)
Goto Top
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).

Das kann sein, da wir Smartphones für Email- und Terminsynchronisation verwenden.
Member: Dr.Cornwallis
Dr.Cornwallis Sep 01, 2015 at 11:01:42 (UTC)
Goto Top
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
Member: appleseed
appleseed Sep 01, 2015 at 11:20:32 (UTC)
Goto Top
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
Member: SeriousEE
Solution SeriousEE Sep 01, 2015, updated at Sep 16, 2015 at 09:41:05 (UTC)
Goto Top
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/Server
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
Member: freenode
freenode Sep 01, 2015 at 12:54:18 (UTC)
Goto Top
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 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/Server
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, mal ne blöde Frage: In welchem Protokoll vom Eventlog suchst Du denn da? Ganz normal im System?
Member: emeriks
emeriks Sep 01, 2015 at 13:08:07 (UTC)
Goto Top
Sicherheit
Member: Chonta
Chonta Sep 01, 2015 at 13:08:59 (UTC)
Goto Top
Hallo,

Hi, mal ne blöde Frage: In welchem Protokoll vom Eventlog suchst Du denn da? Ganz normal im System?

Sicherheit?

Gruß

Chonta
Member: freenode
freenode Sep 03, 2015 at 09:22:56 (UTC)
Goto Top
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 Caller Computer Name und damit wieder der auslösende Client/Server
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.

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.
Member: freenode
freenode Sep 16, 2015 at 09:41:26 (UTC)
Goto Top
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 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/Server
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

Punkt 2 war die Lösung. Danke an alle! face-smile
Member: Dr.Cornwallis
Dr.Cornwallis Sep 20, 2015 at 15:22:18 (UTC)
Goto Top
sag ich doch face-wink> 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 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/Server
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

Punkt 2 war die Lösung. Danke an alle! face-smile