none
Benutzer ständig gesperrt RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo,

    wir haben in unserer AD Domäne einige Benutzer die ständig gesperrt sind. Es handelt sich immer um die gleichen Benutzer.

    Eingabefehler des Benutzers können wir ausschließen. In der Ereignisanzeige vom DC haben filtern wir nach ID 4771 (Kerberos-Authentifizierungsdienst) und sehen im Fehlercode 0x12 die schon gesperrten Konten bzw. 0x18 für einige Fehlversuche. Die Fehlversuche sind teilweise sehr häufig (gleiche Sekunde) hintereinander.

    Dieses ungewöhnliche Verhalten tritt eigentlich erst auf, seitdem wir AD auf Windows 2016 (1607) im letzten Jahr umgestellt haben. Domänenfunktionsebene ist noch 2008 R2. Es ist nur ein DC im Netz mit aktuellen Windows Updates (Stand 04/2019).Mit dem Tool lockoutstatus kann man zwar sehen, wann beim betroffenen Benutzer das letzte Mal ein falsches Passwort gezählt wurde, aber schlüssig wird das ganze nicht.

    Evtl. hat noch einer von Euch eine Idee.

    Vielen Dank.

    Chris

    Freitag, 26. April 2019 12:05
    |

Antworten

  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    hier noch meine ausstehende Antwort:

    Wir haben den Übeltäter gefunden. Die fehlerhaften Loginversuche kommen von einem Azure Server der per VPN an unsere Domäne angebunden ist. Wir haben zum Auffinden der Quelle die Logging Optionen fürs netlogon Protokoll auf dem DC um die Optionen Misc Debug und Critical Events erweitert und sind so dem Server auf die Spur gekommen.

    Jetzt müssen wir nur noch diesen Server ruhig stellen und dann passt es.

    Viele Grüße

    Chris

    Montag, 13. Mai 2019 05:17
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Moin,

    aus den Logs müsst ihr ersehen können, welcher Computer die fehlerhaften Versuche auslöst. Oft ist es ein Exchange-Server (Stichwort: altes Smartphone liegt noch rum und ist geladen) oder ein Scheduled Task, wo man das Kennwort abgespeichert hat. 

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Freitag, 26. April 2019 14:36
    |
  • Question
    Anmelden
    1
    Anmelden
    Habt ihr Netzwerkscanner, die gespeicherten User Credentials haben, im Einsatz? Das wäre auch so ein potentieller Kandidat.
    Freitag, 26. April 2019 14:55
    |
  • Question
    Anmelden
    0
    Anmelden

    Danke für den Tipp.

    Ich hab auch schon vermutet, ob es am O365 (mit AD-Sync) liegt, aber dort werden keine Login-Fehlversuche angezeigt. Hab jetzt noch einen Servereintrag gefunden, der per LDAP auf die AD-Konten zugreift und warte mal auf das Ergebnis des Protokolls.

    Freitag, 26. April 2019 14:56
    |
  • Question
    Anmelden
    1
    Anmelden
    Hi,
     
    Am 26.04.2019 um 14:05 schrieb Chris Rimbach:
    > wir haben in unserer AD Domäne einige Benutzer die ständig gesperrt sind.
     
    Kontosperrung ist der simpelste Denial of Service, den du aktiv einbauen
    kannst.
     
    - JEDER! darf das AD lesen
    - Erstellen einer Liste aller Domain User Accounts per net user /domain
    - fehl-authentifizierung mit Fake Kennwort gegen einen DC "foreach in Liste"
    --> Bumms, kaputt.
     
    Fertiges Script gefällig?
     
    Kontosperrung ist Mist. Logging/SIEM/etc ist der einzige effektive Weg.
     
    Tschö
    Mark
    --
    Mark Heitbrink
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    Samstag, 27. April 2019 13:51
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi Mark,

    die meisten Befehle sind mir bekannt. Aber das man mit dem Skript so leicht die Kollegen ärgern kann ist genial ;-) naja Spaß beiseite.

    Du hast schon recht damit...

    Ich habe mir jetzt nochmal auf dem AD das Protokollieren der Anmeldeversuche per Gruppenrichtlinie angeschaut. Finde ich irgendwo eine einfache Möglichkeit wo ich sehe von wo sich ein Benutzer angemeldet hat. Die Authentifizierung erfolgt ja immer gegen den DC und der sperrt dann die Konten.

    Kannst du evtl. ein Tool evtl. auch ein Boardmittel empfehlen.

    Danke.

    Chris

    Montag, 29. April 2019 14:12
    |
  • Question
    Anmelden
    1
    Anmelden
    Die Regel sollte schon die Kontosperrung, z.B. nach N-Versuchen, sein.
    Denn ansonsten kann man ja ewig die verschiedensten Kennworte generieren bis man dann doch drin ist.
    Montag, 29. April 2019 14:41
    |
  • Question
    Anmelden
    1
    Anmelden

    Finde ich irgendwo eine einfache Möglichkeit wo ich sehe von wo sich ein Benutzer angemeldet hat. Die Authentifizierung erfolgt ja immer gegen den DC und der sperrt dann die Konten.

    Kannst du evtl. ein Tool evtl. auch ein Boardmittel empfehlen.


    https://devblogs.microsoft.com/scripting/use-powershell-to-find-the-location-of-a-locked-out-user/

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 29. April 2019 14:42
    |
  • Question
    Anmelden
    0
    Anmelden
    Hi,
     
    Am 29.04.2019 um 16:41 schrieb bfuerchau:
    > Die Regel sollte schon die Kontosperrung, z.B. nach N-Versuchen, sein.
     
    Erkläre bitte einem produzierendem Gewerbe mit 5-stellig Benutzer die
    Bevorzugung eines Denial of Services inkl. Betriebsausfall für 2-8
    Stunden gegen ein "ordentliches" SIEM. Es darf auch MS ATA sein ...
     
    Am Ende werden ja die sensitiven Konten über ein PSO von der Sperrung
    exkludiert, damit die Admins aktiv werden können zur Diagnose. Denn die
    _adm, admin-, ad-, *ad*, svc_, service etc Konten sind ja die ersten aus
    der liste die ich Sperre ;-)
     
    Tschö
    Mark
    --
    Mark Heitbrink
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    Montag, 29. April 2019 19:09
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo zusammen,

    hier noch meine ausstehende Antwort:

    Wir haben den Übeltäter gefunden. Die fehlerhaften Loginversuche kommen von einem Azure Server der per VPN an unsere Domäne angebunden ist. Wir haben zum Auffinden der Quelle die Logging Optionen fürs netlogon Protokoll auf dem DC um die Optionen Misc Debug und Critical Events erweitert und sind so dem Server auf die Spur gekommen.

    Jetzt müssen wir nur noch diesen Server ruhig stellen und dann passt es.

    Viele Grüße

    Chris

    Montag, 13. Mai 2019 05:17
    |