none
AD Benutzer wird immer wieder gesperrt RRS feed

  • Frage

  • Hi,

    wir haben bei uns in der AD einen User der immer ca. nach 3 Std gesperrt wird. In der Ereignisnazeige wird die ID 4771 und 4776 Protokolliert. Die Arbeitsstation ist aber immer der DC selber. Ich habe jetzt schon das "Netwrix Account Lockout Examiner" angeschmissen und dieser findet über 60 fehlgeschlagene Logins mit diesem User immer vom DC aus. Leider zeigt er keinen Prozess oder ähnliches an, was dies verursacht. In der "netlogon.log" sind auch mehrere solcher Einträge vorhanden "01/20 10:55:12 [LOGON] [11736] SamLogon: Transitive Network logon of (null)\Username from \\x.x.x.104 (via EXSRV) Entered
    01/20 10:55:12 [LOGON] [11736] SamLogon: Transitive Network logon of (null)\Username from \\x.x.x.104 (via EXSRV) Returns 0xC000006A
    01/20 10:55:12 [LOGON] [11736] SamLogon: Transitive Network logon of (null)\Username from \\x.x.x.104 (via W2K12TS) Entered
    01/20 10:55:12 [LOGON] [11736] SamLogon: Transitive Network logon of (null)\Username from \\x.x.x.104 (via W2K12TS) Returns 0xC000006A
    01/20 10:55:13 [LOGON] [11736]  SamLogon: Transitive Network logon of (null)\Username from \\x.x.x.104 (via SWYXSRV) Entered
    01/20 10:55:13 [LOGON] [11736]  SamLogon: Transitive Network logon of (null)\Username from \\x.x.x.104 (via SWYXSRV) Returns 0xC000006A".

    Ich habe keine Ahnung was dies verursachen könnte. Google mit diesen EventIDs hat mich auch nicht weiter gebracht. Hat sonst noch jemand eine Idee was es könnte?

    Freitag, 20. Januar 2017 10:58

Antworten

  • Problem gefunden!

    Auf dem DC war ein Discovery Agent installiert, der wohl mit dem User konfiguriert war. Daher war auch der DC immer als Quelle in der Ereignislog.

    • Als Antwort markiert Busys Samstag, 28. Januar 2017 20:43
    Samstag, 28. Januar 2017 20:43

Alle Antworten

  • Hallo Busys,

    wird der User auf irgendeinem NICHT-domänen oder NICHT-Windows Client zur Authentifizierung eingesetzt? Ist er evtl. ausführender Nutzer eines Dienstes oder Geplanten Tasks?



    Freundliche Grüße

    Sandro
    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)



    • Als Antwort vorgeschlagen SandroReiter Dienstag, 7. Februar 2017 07:49
    Freitag, 20. Januar 2017 11:16
  • Ich habe nichts dergleichen auf dem DC und auf den anderen PC´s gefunden. Das Netwrix Account Lockout Examiner gibt mir nur das hier aus ...

    Freitag, 20. Januar 2017 11:42
  • Was steht im Windows Ereignislog unter Sicherheit dazu?


    Freundliche Grüße

    Sandro
    MCSA: Windows Server 2012
    Fachinformatiker Fachrichtung Systemintegration (IHK, 07/2013)



    Freitag, 20. Januar 2017 11:47
  • Die beiden Ereignisse ...
    Freitag, 20. Januar 2017 11:53
  • Hi

    Habe auch immer wieder solche Accounts.. Ich nehme an, Dir ist bekannt ob dies ein User Account der an einem Client (PC/Notebook/Mobile/Ipad...) arbeitet oder ein Service Account eines Windows Dienstes oder sonst eines Services ist.

    Falls dies ein User Account ist kannst Du folgendes mal machen:
    -IE Cache, Formulardaten etc etc löschen, gibt so en Menupunkt im IE
    -"Net use" Verbindungen trennen

    Falls alles nichts bringt, Userprofile löschen...

    Bei einen Service Account einfach das PW mal im AD neu setzten und auf dem Windows Dienst.

    Ich setzte den AD Change Auditor für solche Angelegenheiten ein wobei ab und zu sehe ich auch nicht woher ein Account gesperrt wird. Meistens ist dies dann z.B. ein Zugriff eines Mobile Gerätes oder einen externen ZUgriff wie z.B. VPN und oder Citrix

    Gruss

    Gruss Dani

    Freitag, 20. Januar 2017 12:01
  • Hi,

    ist ein normaler Benutzeraccount. IE Cache hab ich geleert und Netzlaufwerke etc. gibt es nicht die über den User laufen. PW am iPhone ist auch geändert. Ich verstehe nur einfach nicht, warum dort immer der DC selber als "verursacher" angezeigt wird. Wenn es von z.B. ActiveSync wäre, dann würde er ja den Exchange anzeigen (wie es bei einem anderen User der Fall war).

    Was ich noch bei Google gefunden habe ist die Richtlinie "LAN Manager Authentifizierungsebene" die bei uns auf "Nur NTLM-Antworten senden" stand. Diese habe ich nun mal auf "nicht mehr definiert" gesetzt. Mal schauen ob das was bringt?!

    Freitag, 20. Januar 2017 12:16
  • Am 20.01.2017 schrieb Busys:

    Hi,

    Ho,

    du könntest sinnvoller- und netterweise auf deinen Thread hier hinweisen:
    http://www.msxforum.de/community/index.php/Thread/15932-AD-Benutzer-wird-immer-wieder-gesperrt/?postID=89553#post89553

    Bye
    Norbert


    Dilbert's words of wisdom #18:
    Never argue with an idiot. They drag you down to their level then beat you with experience.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Freitag, 20. Januar 2017 12:26
  • Danke Norbert ;)

    Also entweder die Richtlinie hat nichts bewirkt oder die Clients haben diese noch nicht übernommen. Genau 3 Std nach dem letzten fehlerhaften Login geht es wieder los. Jeder Rechner meldet sich beim DC mit "Transitive Network logon of (null)\Liebhardt from \\x.x.137.104 (via MATTHIAS-PC) Returns 0xC000006A".

    Freitag, 20. Januar 2017 13:20
  • Das tönt aber schon nach Policy (3 Std) wobei ich nehme an, dass alle Clients die selbe Policy erhalten. Sonst soll der User doch mal an einen anderen Client...

    "LAN Manager authentication Level" muss auf dem Client sowie auf dem DC miteinander kompatibel sein. Kann es sein, dass der User eine Applikation startet deren NTML Level tiefer ist als die Policy auf dem DC? Vergleiche doch mal diese und schau mal nach wie vielen Minuten der Client ein Policy refresh macht.

    Gruss

    Freitag, 20. Januar 2017 14:12
  • Habe soeben noch folgendes in der netlogon.log gefunden ...

    01/20 16:16:28 [MAILSLOT] [3724] Received ping from W2K12DC(W2k12DC.domäne.local) (null) (null) on <Local>
    01/20 16:16:28 [CRITICAL] [3724] Ping from W2K12DC for domain (null) a for (null) on <Local> is invalid since we don't host the named domain.
    01/20 16:16:28 [MISC] [3724] NetpDcGetName: a similar query failed recently 13109
    01/20 16:16:28 [MISC] [3724]  DsGetDcName function returns 1355 (client PID=10808): Dom:a Acct:(null) Flags: NETBIOS RET_DNS
    01/20 16:16:28 [MISC] [3724]  DsGetDcName function called: client PID=10808, Dom:a Acct:(null) Flags: NETBIOS RET_DNS
    01/20 16:16:28 [MISC] [3724] NetpDcInitializeContext: DSGETDC_VALID_FLAGS is c07ffff1
    01/20 16:16:28 [MAILSLOT] [3724] Received ping from W2K12DC(W2k12DC.domäne.local) (null) (null) on <Local>
    01/20 16:16:28 [CRITICAL] [3724] Ping from W2K12DC for domain (null) a for (null) on <Local> is invalid since we don't host the named domain.

    Freitag, 20. Januar 2017 15:25
  • hi Bushs,

    nutzt du handysync? ich hatte einmal einen Kollegen der hatte sein Androide seiner Tochter weitergegeben und das Passwort wurde inzwischen in der Firma geändert. Androide versuchte es weiter mit dem alten Pwd und sperrte den User regelmässig.

    eine andere Möglichkeit ist der Tresor (Benutzerverwaltung - Kennwörter heißt es glaube) wenn dort ein Kennwort gespeichert wurde (sollte eigentlich total leer sein) dann wir beim IE Aufruf ebenfalls immer dieses verwendet und sperrt dir den AD User.


    Chris

    Samstag, 21. Januar 2017 12:43
  • Hi,

    alles schon geprüft. Problem ist ja, dass die Clientadresse ::1 lautet die das Problem verursacht. Also scheint der DC selber das zu verursachen. Als Arbeitsstation steht immer wieder der Name des DC´s und die IP Adresse des DC´s in den Log´s. Wenn man danach googelt findet man immer nur das bei der Clientadresse wirklich ein Client angegeben ist und nicht "localhost". Und der Dienstname ist immer "krbtgt/Domänenname" angegeben.

    Samstag, 21. Januar 2017 13:56
  • Am 21.01.2017 schrieb Busys:
    Hi,

    alles schon geprüft. Problem ist ja, dass die Clientadresse ::1 lautet die das Problem verursacht. Also scheint der DC selber das zu verursachen. Als Arbeitsstation steht immer wieder der Name des DC´s und die IP Adresse des DC´s in den Log´s. Wenn man danach googelt findet man immer nur das bei der Clientadresse wirklich ein Client angegeben ist und nicht "localhost". Und der Dienstname ist immer "krbtgt/Domänenname" angegeben.

    Im Netlogon.log steht aber eben nicht immer der DC drin. Dass der DC als "sperrende" Maschine auftaucht ist doch auch irgendwie logisch würde ich sagen. Wie groß is denn das gesamte Netzwerk?

    Bye
    Norbert


    Dilbert's words of wisdom #32:
    If it wasn't for the last minute, nothing would get done.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Samstag, 21. Januar 2017 23:17
  • Selbst unsere Serverüberwachung zeigt an, dass es immer der DC selber ist. Testweise mal mit nem MacBook versucht und siehe da dieses wird dann auch angezeigt.

    Netzwerk besteht zu ca. 30 Clients und 7 Server.


    • Bearbeitet Busys Sonntag, 22. Januar 2017 13:18
    Sonntag, 22. Januar 2017 13:01
  • Am 22.01.2017 schrieb Busys:

    Selbst unsere Serverüberwachung zeigt an, dass es immer der DC selber ist. Testweise mal mit nem MacBook versucht und siehe da dieses wird dann auch angezeigt.<https://social.technet.microsoft.com/Forums/getfile/992207>

    Ja logisch ist es der DC, der das Konto sperrt. Oder versteh ich dich falsch?

    Netzwerk besteht zu ca. 30 Clients und 7 Server.

    Na dann wärs doch wahrscheinlich "überschaubar", mal der Reihe nach alles auszuschalten und zu prüfen bei welchem Server/PC die Sperrung erfolgt. Ich tippe auf entweder "irgendwelche Laufwerke", Tasks oder eine vergessene Terminalsession auf einem Server.

    Bye
    Norbert

    Sonntag, 22. Januar 2017 18:50
  • Am 22.01.2017 schrieb Busys:

    Selbst unsere Serverüberwachung zeigt an, dass es immer der DC selber ist. Testweise mal mit nem MacBook versucht und siehe da dieses wird dann auch angezeigt.<https://social.technet.microsoft.com/Forums/getfile/992207>

    Ja logisch ist es der DC, der das Konto sperrt. Oder versteh ich dich falsch?

    Ich meine damit wenn dort als Quelle der DC steht, muss etwas auf dem DC sich versuchen anzumelden was auf dem DC läuft. Ansonsten wird ja wie beim MacBook das MacBook als "Ursache" angezeigt. Oder seh ich das falsch?

    Ich habe auf dem Terminalserver mit dem Netwrix Account Lockout Examiner noch einen Task gefunden "Optimize Start Menue Cache" der auf den Benutzer gesetzt war, allerdings war dieser deaktiviert und lief am 14.1 das letzte Mal. Hab diesen nun mal gelöscht. Mal sehen, ob es was bringt.

    Hab damit alle laufende Server mit geprüft und Clients laufen momentan keine.
    • Bearbeitet Busys Sonntag, 22. Januar 2017 21:31
    Sonntag, 22. Januar 2017 21:20
  • Am 22.01.2017 schrieb Busys:
    Hi,

    Ich meine damit wenn dort als Quelle der DC steht, muss etwas auf dem DC sich versuchen anzumelden was auf dem DC läuft. Ansonsten wird ja wie beim MacBook das MacBook als "Ursache" angezeigt. Oder seh ich das falsch?

    Also das zu verifizieren, dauert nun wirklich keine 3 Minuten. ;) Nimm ein anderes Konto und melde dich x mal falsch an und schau was im Log steht, oder?

    Bye
    Norbert


    Dilbert's words of wisdom #34:
    When you don't know what to do, walk fast and look worried.
    nntp-bridge Zugriff auf die MS Foren wieder möglich: https://communitybridge.codeplex.com/

    Sonntag, 22. Januar 2017 21:37
  • Ja eben da steht dann der Client von dem der Fehllogin ausgeht. Bei dem einen User steht aber immer als Client die IP vom DC und der Name vom DC.

    Achja und der eine geplante Task war es leider nicht.

    Montag, 23. Januar 2017 10:26
  • Also wenn ich den DC neustarte sind direkt danach die krbtgt Fehler in der Ereignislog. Kann es sein, dass es auch direkt an dem krbtgt Dienst selber liegt?

    Ich werde mal schauen, ob ich heute Abend den Server mit einem leeren virtuellen Switch neustarten kann und ob dann die Fehler noch immer auftreten, wenn kein Gerät mehr eine Verbindung zum DC hat.

    Dienstag, 24. Januar 2017 09:30
  • Habe das nun wie oben geschrieben versucht. Ich hab dann auf dem DC Wireshark gestartet und den Server dann wieder ins normale Netz gehängt und gewartet bis die Ereignisse auftauchen (was nach ein paar Sekunden bereits der Fall ist/war).

    So wie es aussieht kommen die Fehllogins vom Exchange. Nur ist auch dort nicht ersichtlich durch was dies passiert. Sind keine Netzlaufwerke, RDP Sessions, Geplante Tasks etc. darauf vorhanden. Auf dem Exchange wird auch die ID 4776 protokolliert mit dem Fehlercode 0xC0000064 was ja so viel heißt Benutzer existiert nicht.

    Also ich hab nun keine Ahnung mehr was ich noch machen kann :/

    Dienstag, 24. Januar 2017 19:45
  • Problem gefunden!

    Auf dem DC war ein Discovery Agent installiert, der wohl mit dem User konfiguriert war. Daher war auch der DC immer als Quelle in der Ereignislog.

    • Als Antwort markiert Busys Samstag, 28. Januar 2017 20:43
    Samstag, 28. Januar 2017 20:43
  • Am 28.01.2017 um 21:43 schrieb Busys:

    Problem gefunden!

    Auf dem DC war ein Discovery Agent installiert, der wohl mit dem User konfiguriert war. Daher war auch der DC immer als Quelle in der Ereignislog.

    Sehr schön. Das war innerhalb des Agents, oder der Service lief unter diesem Account?

    Bye
    Norbert

    Sonntag, 29. Januar 2017 23:51
  • Das war innerhalb des Agents, deshalb war die Suche auch so schwer. Habe es erst mit Procmon ruasgefunden.
    Montag, 30. Januar 2017 07:48