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:
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 :
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
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
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 7523303588
Url: https://administrator.de/contentid/7523303588
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
20 Kommentare
Neuester Kommentar
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 ...
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 ...
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
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
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
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
Moin
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ß
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...
(...) 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ß
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
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 ?
Allerdings wenn alles auf einem Server installiert ist dann wird das schon schwieriger
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 ?
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 .......
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 .......
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)
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)
Zitat von @MrHeisenberg:
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
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)
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.