mrheisenberg
Goto Top

DAU oder doch nicht? AD Kontosperre

Moin Leute,

frage an das Schwarmwissen, entweder ich besitze einen DAU bei mir im AD oder hier handelt es sich um einen Fehler...
Was passiert:
Der User sperrt sich nach einer gewissen Zeit selbst, und wir wissen nicht warum, Kontosperrung nach 8x falscher PW-Eingabe, der User hat "nur" ein Laptop & ein Iphone mit Mailsync über unseren Exchange 2016.
AD ist derzeit noch ein Winserver 2016, Gerät wurde bereit neu Aufgesetzt, User Zurückgesetzt, sowie die Maileinstellungen am iOS Gerät geprüft, soweit alles in Ordnung....

Mit diesen Skript logge ich im Hintergrund mit wann sich der User an, bzw. Abmeldet:

if (-not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Write-Host "Das Skript muss mit Administratorrechten ausgeführt werden." -ForegroundColor Red  
    exit
}


function Start-UserLogonLogoffMonitoring {
    Param(
        [Parameter(Mandatory = $true)]
        [string]$userName
    )

    $logonEventID = 4624
    $logoffEventID = 4634

    $filterXml = @"  
<QueryList>
  <Query Id="0" Path="Security">  
    <Select Path="Security">  
        *[System[(EventID=$logonEventID or EventID=$logoffEventID)]]
        and
        *[EventData[Data[@Name='TargetUserName']='$userName']]  
    </Select>
  </Query>
</QueryList>
"@  

    $events = Get-WinEvent -FilterXml $filterXml -ErrorAction SilentlyContinue

    if (!$events) {
        Write-Host "Es wurden keine Logon- oder Logoff-Ereignisse für den Benutzer $userName gefunden." -ForegroundColor Yellow  
        return
    }

    $eventHash = @{}
    foreach ($event in $events) {
        $eventHash[$event.RecordId] = $event
    }

    Write-Host "Starte die Überwachung von Logon- und Logoff-Ereignissen für den Benutzer $userName. Drücke [Ctrl+C], um zu beenden."  

    while ($true) {
        $newEvents = Get-WinEvent -FilterXml $filterXml -ErrorAction SilentlyContinue | Where-Object { $_.RecordId -notin $eventHash.Keys }

        foreach ($event in $newEvents) {
            $eventHash[$event.RecordId] = $event

            if ($event.Id -eq $logonEventID) {
                $eventType = "Logon"  
            }
            elseif ($event.Id -eq $logoffEventID) {
                $eventType = "Logoff"  
            }

            $timeStamp = $event.TimeCreated
            $computerName = $event.MachineName

            Write-Host "[$timeStamp] [$eventType] Benutzer $userName angemeldet am Computer $computerName"  
        }

        Start-Sleep -Seconds 1
    }
}

$userName = Read-Host "Gib den Benutzernamen ein:"  
Start-UserLogonLogoffMonitoring -userName $userName

und mit diesen kleinen Skript kontrolliere ich wann sich de rUser gesperrt hat, um einen Timestamp zu erhalten um mit dem oben genannten Skript gegen zu prüfen :

if (-not ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
    Write-Host "Das Skript muss mit Administratorrechten ausgeführt werden." -ForegroundColor Red  
    exit
}

function Get-LockedOutUserEvents {
    Param(
        [Parameter(Mandatory = $true)]
        [string]$userName
    )

    $lockoutEventID = 4740
    $unlockEventID = 4767

    $filterXml = @"  
<QueryList>
  <Query Id="0" Path="Security">  
    <Select Path="Security">  
        *[System[(EventID=$lockoutEventID or EventID=$unlockEventID)]]
        and
        *[EventData[Data[@Name='TargetUserName']='$userName']]  
    </Select>
  </Query>
</QueryList>
"@  

    $events = Get-WinEvent -FilterXml $filterXml -ErrorAction SilentlyContinue

    if (!$events) {
        Write-Host "Es wurden keine Sperrungs- oder Entsperrungsereignisse für den Benutzer $userName gefunden." -ForegroundColor Yellow  
        return
    }

    foreach ($event in $events) {
        $eventType = if ($event.Id -eq $lockoutEventID) { "Sperrung" } else { "Entsperrung" }  
        $timeStamp = $event.TimeCreated
        $computerName = $event.MachineName

        Write-Host "[$timeStamp] [$eventType] Benutzer $userName auf dem Computer $computerName"  
    }
}

$userName = Read-Host "Gib den Benutzernamen ein:"  
Get-LockedOutUserEvents -userName $userName

Aber ich finde keinen offensichtlichen Fehler, der User ist auch der Einzige was es schafft sich am Tag gefühlt 300x zu sperren... und für einen Social-Media-Manager dreh ich sicherlich nicht meine Kennwortrichtlinien ab... jetzt gehen natürlich die wogen hoch und ich steh sozusagen "a bissl mit dem Buckel zur Wand" ich hab echt keine Idee mehr was ich noch alles Mitloggen soll/kann damit ich den Fehler finde, weil jetzt zu behaupten der User ist zu Bl** um ein Gerät zu bedienen wäre relativ leicht, und hierfür würde ich Handfeste Beweise benötigen... Hatte schon mal wer so einen Fall und hat eine Idee oder gar eine Lösung für mich? (den User aus der Firma zu befördern ist leider keine Option... hab ich schon bei meinen Leiter abgeklopft :D )


Grüße

Content-ID: 7523303588

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

Ausgedruckt am: 25.11.2024 um 11:11 Uhr

papapishu
papapishu 14.06.2023 um 14:41:19 Uhr
Goto Top
Moin zurück,

kann es am WLAN Login per RADIUS liegen?
Das sperrt gerne mal die AD Konten.
MirkoKR
MirkoKR 14.06.2023 um 14:45:04 Uhr
Goto Top
hi.

Erste Idee, weil schonmal gehabt:

habt ihr einen onPrem oder Azur- Server der Dienste zur Inhalte ausliefert oder Zugänge zu Social Media Accounts verwaltet?

GGF. hat er sich dort mit seinem AD-Konto und einem noch nicht geänderten alten Passwort angemeldet und diese gespeichert, sodass irgendein Dienst versucht sich mit den alten Daten einzuloggen?

Könnte auch Windows Dienst oder ein Geplanter Task irgendwo sein der auf sein AD Konto zugreift ...
MrHeisenberg
MrHeisenberg 14.06.2023 um 14:46:19 Uhr
Goto Top
Zitat von @papapishu:

Moin zurück,

kann es am WLAN Login per RADIUS liegen?
Das sperrt gerne mal die AD Konten.

Zu meiner Schade muss ich gestehen dass unser RADIUS-Server derzeit noch nicht läuft, somit fällt dieser Ansatz leider raus

Grüße
Nils02
Lösung Nils02 14.06.2023 um 14:47:57 Uhr
Goto Top
Moin,

hast du hiermit schonmal geschaut: https://www.netwrix.de/account_lockout_examiner.html
Ist kostenlos und gibt zumindest ein paar mögliche Gründe für die Sperrung, z. B. Human Error.

Aber wichtiger hinweis was ich so auch zunächst nicht glauben wollte:

Gibt der User "abc" als Passwort ein und es ist falsch, gibt das einen bad login.
Versucht er jetzt noch 10x "abc" bleibt der bad login count trotzdem bei 1.

Das bedeutet, selbst wenn in einem Dienst das alte Passwort hinterlegt sein sollte, solange es nur das eine Passwort verwendet, gibt es nur einen bad login.

Du könntest mal testen ob sich der User ebenfalls sperrt, wenn Windows Hello(Fingerabdruck oder Gesicht) zur Anmeldung verwendet wird.

Auf deinem DC müsstest du ebenfalls den Quellcomputer bzw. die IP für die Anmeldung sehen.

LG
Mr-Gustav
Mr-Gustav 14.06.2023 um 14:50:07 Uhr
Goto Top
Was passiert denn wenn du beim entsprechenden User unter KONTO im AD mal den Haken bei: "Kennwort mit umkehrbarer Verschlüsselung speichern" setzt.
Wir hatten mal irgendein Problem mit dem OS oder einer Software welche zum Zeitpunkt X den Account Permanent gesperrt hat. Weiß nicht mehr was das war. Wir hatten ewig gesucht und meistens nach 30min ein neu Deployment gemacht.
Was damals als Work Around gehplfen hat war das obere. Ein mal gesetzt - Angemeldet und dann den Haken wieder raus und das Problem war gelöst.
Ich schau später mal in der Doku vllt. hat da mal jemand was dokumnetiert
Hubert.N
Hubert.N 14.06.2023 aktualisiert um 15:01:13 Uhr
Goto Top
Moin

Zitat von @MrHeisenberg:
(...) weil jetzt zu behaupten der User ist zu Bl** um ein Gerät zu bedienen wäre relativ leicht, und hierfür würde ich Handfeste Beweise benötigen...

Wie wäre es, den Benutzernamen im AD einfach mal zu ändern?

Normalerweise solltest Du auch sehen können, von wo aus die Anmeldungen erfolgen.

Gruß
Mr-Gustav
Mr-Gustav 14.06.2023 aktualisiert um 15:06:10 Uhr
Goto Top
Das wäre natürlich das erste was man machen sollte. Im Zweifel gibts da ein Tool von den Sysinternals wo man dies nachsehen kann. Accountlocout oder so ist der Name den ich in Erinnerung hatte.
Allerdings wenn alles auf einem Server installiert ist dann wird das schon schwieriger face-smile
Wir haben deswegen verschiedene DC´s bzw. RODC welche für die verschiedenen Services genutzt werden. Durch die verschiedenen DC´s bzw. RODC kann man, wenn man weiß welcher Service durch den DC/RODC versorgt wird, dann auf die Anwendung bzw. auf den Service ( VPN / MDM / ADFS / etc. ) schließen

Ähh was mir noch einfällt:
Hat der Kollege eventuell irgendwo ein Script laufen wo er Benutzer/Passwort eingetragen hat?
Hatten wir öfters weil Kollegen meinten Sie müssen irgendwas automatisch per Robocopy wegkopieren wollten und haben dann vergessen das Kennwort zu ändern. Oder hat der Kollege ggf. irgendwo einen Service laufen der auf Benutzername und Kennwort für die Anmeldung verwendet ?
Coreknabe
Lösung Coreknabe 14.06.2023 um 15:11:44 Uhr
Goto Top
Moin,

beliebter Fehler bei uns, auch wenn wir die User nach x Fehlversuchen nicht sperren:
Auf irgendeinem Endgerät läuft eine Verbindung zum Mailserver und dort ist noch das falsche Passwort hinterlegt.

Gruß
PeterPanter
Lösung PeterPanter 14.06.2023 um 15:12:24 Uhr
Goto Top
Moin,
ich checke bei solchen Dauer-Sperrern erstmal die Event-Logs auf dem AD-Controller. Windows-Protokolle - Sicherheit / Filtern nach ID=4740. Dann sieht man wann und vor allem mit welchem Aufrufcomputername das Konto gesperrt wurde.

Das grenzt schonmal ein...

2023-06-14 15_09_56

/pp
Mr-Gustav
Mr-Gustav 14.06.2023 um 15:15:07 Uhr
Goto Top
Wenn da dort dann Client Computer direkt angezeigt werden ist es ggf. ein Lokales Problem.
Wenn es hingegen ein DC ist dann kann es auch sein das die Sperrung von einem anderen DC übertragen wurde. Dann heißt es die Spur zu verfolgen face-smile
Kelbur
Kelbur 14.06.2023 um 16:27:56 Uhr
Goto Top
Das Problem hatte ich vor ein paar Jahren auch mal mit einem User. Lösung war das er auf dem Rechner nach Kennwortrichtlinie sein PW geändert hatte, auf dem iPhone aber nicht und trotzdem noch eine gewisse Zeit seine Mails abrufen konnte.
MrHeisenberg
MrHeisenberg 14.06.2023 um 16:39:01 Uhr
Goto Top
Moin Leute,

danke für euren Input, hat mich schon um einiges Weitergebracht, ich bin eure Lösungsvorschläge durchgegangen und der Tipp von @PeterPanter hat mich dem Ziel etwas näher gebracht, der User sperrt sich am Mailserver...

Wir werden jetzt dem User mal sein Telefon abknöpfen und nochmals nachsehen was Sache ist, bzw. auf dem Gerät den Outlook nochmals neu Einrichten... Irgendwo ist der Hund begraben, aber ich bin etwas perplex da ich bei der Einrichtung immer die doppelte Kontrolle mache, und es hat ja funktioniert.... kommt mir langsam vor wie das Bermuda-Dreieck...


Grüße
Kelbur
Kelbur 14.06.2023 um 16:42:16 Uhr
Goto Top
dann wird er dort das neue PW nicht hinterlegt haben, siehe mein Kommentare
MrHeisenberg
MrHeisenberg 14.06.2023 um 17:00:33 Uhr
Goto Top
Danke Leute,

hab die Lösung, @Nils02 sein Programmvorschlag brachte gerade den Durchbruch, siehe Screenshot, eigtl. sollte/darf/muss nur ein iOS Gerät mit dem Mailserver eine Verbindung aufbauen, aber hier haben wir den klassischen Fall: "der IT Typ sagt irgendwas mit ist´s egal ich knall mein Mailing überall drauf wo ich will"


Ich bedanke mich, und kann nun sicher sein dass nicht ich einen Knacks hab...


Grüße
screenshot 2023-06-14 170002
Mr-Gustav
Mr-Gustav 15.06.2023 um 11:07:52 Uhr
Goto Top
Wenn ein Handy einen Account sperren kann dann würde ich mir mal Gedanken über meine MDM und Mobile Strategie machen weil wenn das so einfach geht dann kann das auch mal nach hinten los gehen.
Wenn jetzt jemand versucht den Administrator oder eben einen Service User von Außen über ein Mobiltelefon zu sperren ( durch falsche PW Eingabe ) ......... NICHT GUT ! Sollte so nicht möglich sein.
Wenn bei uns die Telefone keine gültigen Kennwörter mehr haben so bleibt das ganze auf das Mobiltelefon beschränkt.
Wäre ja blöd wenn jemand über einen Brutforce die Firma lahm legt weil er in der Mobile Phone Mail App die Admini Accounts und Standard Account sperrt .......
elix2k
elix2k 15.06.2023 um 14:20:42 Uhr
Goto Top
Der Exchange Server bietet für solche Szenarien auch eine Quarantäne Funktion. Da können sich die User an zig Geräten anmelden, kommen aber ohne deine Zustimmung nicht weiter.
CypH3r-LE
CypH3r-LE 17.06.2023 um 09:31:57 Uhr
Goto Top
Servus,

Auch wenn das ganze erledigt ist, kann sich mein Monk leider nicht zurück halten.

Auch wenn du es nicht speicherst, solltest du mit dem ersten Script Vorsicht sein (sofern eure Firmenpolitik dies nicht geregelt hat). Das tracken von Personenbezogenen Daten mit Zeitstempel finden manche Betriebsräte nicht ganz so witzig. (BS eigene Mittel sind da meist ausgenommen)
MrHeisenberg
MrHeisenberg 19.06.2023 um 08:00:44 Uhr
Goto Top
Zitat von @Mr-Gustav:

Wenn ein Handy einen Account sperren kann dann würde ich mir mal Gedanken über meine MDM und Mobile Strategie machen weil wenn das so einfach geht dann kann das auch mal nach hinten los gehen.
Wenn jetzt jemand versucht den Administrator oder eben einen Service User von Außen über ein Mobiltelefon zu sperren ( durch falsche PW Eingabe ) ......... NICHT GUT ! Sollte so nicht möglich sein.
Wenn bei uns die Telefone keine gültigen Kennwörter mehr haben so bleibt das ganze auf das Mobiltelefon beschränkt.
Wäre ja blöd wenn jemand über einen Brutforce die Firma lahm legt weil er in der Mobile Phone Mail App die Admini Accounts und Standard Account sperrt .......

Moin,

stimme ich zu, wir sind gerade dabei unsere Systeme zu härten, also es kann nur noch besser werden

Grüße
MrHeisenberg
MrHeisenberg 19.06.2023 um 08:01:54 Uhr
Goto Top
Zitat von @CypH3r-LE:

Servus,

Auch wenn das ganze erledigt ist, kann sich mein Monk leider nicht zurück halten.

Auch wenn du es nicht speicherst, solltest du mit dem ersten Script Vorsicht sein (sofern eure Firmenpolitik dies nicht geregelt hat). Das tracken von Personenbezogenen Daten mit Zeitstempel finden manche Betriebsräte nicht ganz so witzig. (BS eigene Mittel sind da meist ausgenommen)

Moin,

da Tracking wurde im DV verankert damit wir dies nutzen können bei genau solchen fällen... Frage nicht was das für ein Zenober war.

Grüße
CypH3r-LE
CypH3r-LE 19.06.2023 um 08:57:54 Uhr
Goto Top
Zitat von @MrHeisenberg:

Zitat von @CypH3r-LE:

Servus,

Auch wenn das ganze erledigt ist, kann sich mein Monk leider nicht zurück halten.

Auch wenn du es nicht speicherst, solltest du mit dem ersten Script Vorsicht sein (sofern eure Firmenpolitik dies nicht geregelt hat). Das tracken von Personenbezogenen Daten mit Zeitstempel finden manche Betriebsräte nicht ganz so witzig. (BS eigene Mittel sind da meist ausgenommen)

Moin,

da Tracking wurde im DV verankert damit wir dies nutzen können bei genau solchen fällen... Frage nicht was das für ein Zenober war.

Grüße

Servus,

Mein Monk macht Luftsprünge.
Glaub ich dir gern.