none
Kennung sperrt sich immer RRS feed

  • Frage

  • Hallo,
    wir haben in einer 2008 R2 Subdomäne einen Domänen Acount der sich immer sperrt.
    Logs durchwühlt......leider finde ich den Übeltäter nicht.
    Vermutlich iwo mal die Kennung missbraucht worden mit einem falschen PW.

    1. Was habe ich für ne Möglichkeit das rauszufinden? Security Logs der DC's schon durchforstet.
    2. Habe ich eine Möglichkeit diesen eine Account aus der PW Richtlinie auszuschließen? Zumindest das der Accout nicht mehr gesperrt wird?

    Danke und Gruß
    Dennis

    Dienstag, 20. März 2018 15:53

Antworten

Alle Antworten

  • Moin,

    damit in den Security Logs was sinnvolles steht, musst Du das Auditing natürlich vorher per Group Policy hoch drehen.

    Ja, mit Fine Grained Password Policy kannst Du diesen Account ausschließen.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    Dienstag, 20. März 2018 16:11
  • Ist das nicht per Default das wenn eine Kennung gesperrt wird das geloggt wird?

    Aktuell ist das gesetzt:
    Lokale
    Richtlinien/Überwachungsrichtlinie
    hide
    Richtlinie Einstellung
    Anmeldeversuche überwachen Erfolgreich, Gescheitert
    Was würdest du noch empfehlen um das raus zu bekommen?
    Dienstag, 20. März 2018 16:35
  • Hallo.

    Wir haben solche Fälle gerne mal, wenn der Anwender ein odere mehrere Mobilegeräte mit dem Exchange synchronisieren lässt. Kann das der Fall sein? Wenn ihr einen Exchange habt, prüfe bei der Kennung doch mal die hinterlegten Active Sync Geräte.

    Wird die Kennung nur dann gesperrt wenn der Anwender angemeldet ist oder auch wenn er komplett abgemeldet ist?

    Gruß


    Ben

    Dienstag, 20. März 2018 20:38
  • Moin,

    nein, fehlgeschlagene Versuche werden per Default nicht überwacht.

    Hier ist die Bibel: https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/security-auditing-overview 

    Im Prinzip, reicht die Basic Policy "Kontoanmeldung - Fehlschlag". Da muss man zwischen "Anmeldung" (User gibt Name / Kennwort ein) und "Kontoanmeldung" (Name / Kennwort werden durch die zuständige Authority bestätigt) unterscheiden.


    Evgenij Smirnov

    I work @ msg services ag, Berlin -> http://www.msg-services.de
    I blog (in German) @ http://it-pro-berlin.de
    my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
    Exchange User Group, Berlin -> https://exusg.de
    Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
    Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.com


    In theory, there is no difference between theory and practice. In practice, there is.

    • Als Antwort markiert HaschkeD Mittwoch, 21. März 2018 16:11
    Dienstag, 20. März 2018 21:08
  • Am 20.03.2018 um 16:53 schrieb HaschkeD:
    > wir haben in einer 2008 R2 Subdomäne einen Domänen Acount der sich immer
    > sperrt.
     
    Anmeldungen protokollieren, Security Event log nach ID 4740 durchsuchen,
     
    The source of my account lockout is my domain controller
     
    Am Client gern genommen: Das AnmeldeTresor / Anmeldeinformationsverwaltung
     
    Tschö
    Mark
    --
    Mark Heitbrink - MVP Group Policy - Cloud and Datacenter Management
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    • Als Antwort markiert HaschkeD Mittwoch, 21. März 2018 16:11
    Dienstag, 20. März 2018 22:28
  • Das ist konfiguriert....sollte ja passen:

    Hab dann mit eventcombMT.exe die DC's (Security Log) nach ID 4740 durchsucht.......findet nix :-(

    Dann mal manuell die Logs durchsucht auf jedem DC......da finde ich was......
    Zumindest einen Hinweis welcher Kontoname und von welcher Station......



    • Bearbeitet HaschkeD Mittwoch, 21. März 2018 16:02
    Mittwoch, 21. März 2018 15:58
  • was sagt den der Tresor des Benutzers. Hatte zufällig diese Woche auch gerade wieder zwei extrem komplizierte Fälle. 5000 Bad Passwort. Bei einem gemeinsamen benutzen User (so wie sie in Krankenhäuser verwendet werden) wurde ein anderer User im Tresor etwas abgespeichert und gestern hatte ich wieder einen Fall das war Office im Tresor und das verursachte 5 Bad Passwort am AD pro Sekunde!!! D.h. User A wurde immer gesperrt User B hatte den Eintrag im Tresor - eh klar, dann man bei Usern jeden Usernamen mit falschen Passwort angeben kann!!! Und das auf einem Terminal Server mit ca. 300-400 Usern. War nicht einfach das zu finden.

    man kann aber am  betreffenden PC der die Sperre verursacht ganz gut im SYSTEM Eventlog mittels STRG-F nach dem User suchen der gesperrt wird. 

    1. Im AD nachsehen welcher PC die Sperre verurscht.

    2. Unter Credentials alle User auf diesem PC nachsehen und ggf. löschen.

    unter %Appdata%/Microsoft/Credentials und auch unter Local/Microsoft/Credentials findest du auch die Hidden Einträge falls du sie per Script löschen möchtest. Beim ersten Problem habe ich sicher 3 Tage trotz div. Tools gesucht!

    Nachtrag: wir nutzen AuditManagerPlus um den PC und gesperrten User leichter herauszufinden. Das nachsehen im Tresor alle Benutzer am betreffenden PC bleibt trotzdem nicht aus.


    Chris


    • Bearbeitet -- Chris -- Mittwoch, 21. März 2018 17:31
    Mittwoch, 21. März 2018 17:28