AD Benutzer clonen wegen Lockout Problem
Hallo Zusammen,
ich habe ein Problem mit einem AD User, welcher alle 10 Minuten im AD gesperrt wird.
Leider haben wir noch nicht herausgefunden warum der Account immer gesperrt wird im AD.
Wir haben in der Firma eine neue Passwort Policy aktiviert und ca. 100 Mitarbeiter mussten ihr Passwort ändern.
Bei 3 Benutzern gab es das Problem das ihr Account immer zu sporadischen Zeiten im AD gesperrt wurde.
Bei 2 Usern konnten wir das Laptop wechseln und seit dem gibt es bei diesen zwei Benutzern keine AD Locks mehr.
Nur bei einem Benutzer hat das leider nicht geholfen und sein Account wird immer gesperrt nach ca. 10 Minuten.
Ich habe ein Powershell Script erstellt und im Taskscheduler hinterlegt, das sein Account alle 5 Minuten automatisch immer entsperrt, falls es gesperrt ist, sodass er zumindest arbeiten kann.
Die Benutzer haben noch Smartphones auf dem der Exchange Account eingehängt ist, aber das haben wir auch entfernt und offline genommen, an dem hat es nicht gelegen.
Auch läuft ein Azure AD Sync, welcher die on-premise AD Daten in die Azure AD synced. Den Dienst haben wir auch gestoppt und am Azure AD Sync liegt es auch nicht.
Jetzt können wir als letzte Instanz nur noch sein AD Account neu anlegen und das Exchange Postfach dem neuen Benutzer zu weisen.
Weiss jemand wie dazu der beste Weg ist? Sollte man erst ein Clone von seinem AD Benutzer machen und anschliessend den bestehenden löschen und dann alles auf den AD Clone Account umbennen und wieder richtig stellen?
Oder gibt es dafür sogar irgend eine Anleitung im Netz? Ich will halt nichts falsch machen, da es sich um den Account eines Geschäftsführers handelt.
In den Eventlogs vom AD Server sieht man immer folgende Meldung wenn sein Account gesperrt wird:
Danke und Gruss
ich habe ein Problem mit einem AD User, welcher alle 10 Minuten im AD gesperrt wird.
Leider haben wir noch nicht herausgefunden warum der Account immer gesperrt wird im AD.
Wir haben in der Firma eine neue Passwort Policy aktiviert und ca. 100 Mitarbeiter mussten ihr Passwort ändern.
Bei 3 Benutzern gab es das Problem das ihr Account immer zu sporadischen Zeiten im AD gesperrt wurde.
Bei 2 Usern konnten wir das Laptop wechseln und seit dem gibt es bei diesen zwei Benutzern keine AD Locks mehr.
Nur bei einem Benutzer hat das leider nicht geholfen und sein Account wird immer gesperrt nach ca. 10 Minuten.
Ich habe ein Powershell Script erstellt und im Taskscheduler hinterlegt, das sein Account alle 5 Minuten automatisch immer entsperrt, falls es gesperrt ist, sodass er zumindest arbeiten kann.
Die Benutzer haben noch Smartphones auf dem der Exchange Account eingehängt ist, aber das haben wir auch entfernt und offline genommen, an dem hat es nicht gelegen.
Auch läuft ein Azure AD Sync, welcher die on-premise AD Daten in die Azure AD synced. Den Dienst haben wir auch gestoppt und am Azure AD Sync liegt es auch nicht.
Jetzt können wir als letzte Instanz nur noch sein AD Account neu anlegen und das Exchange Postfach dem neuen Benutzer zu weisen.
Weiss jemand wie dazu der beste Weg ist? Sollte man erst ein Clone von seinem AD Benutzer machen und anschliessend den bestehenden löschen und dann alles auf den AD Clone Account umbennen und wieder richtig stellen?
Oder gibt es dafür sogar irgend eine Anleitung im Netz? Ich will halt nichts falsch machen, da es sich um den Account eines Geschäftsführers handelt.
In den Eventlogs vom AD Server sieht man immer folgende Meldung wenn sein Account gesperrt wird:
An account failed to log on.
Subject:
Security ID: SYSTEM
Account Name: xxxxx
Account Domain: xxxxxx
Logon ID: 0x3E7
Logon Type: 3
Account For Which Logon Failed:
Security ID: NULL SID
Account Name: xxxxx
Account Domain: xxxxx
Failure Information:
Failure Reason: Unknown user name or bad password.
Status: 0xC000006D
Sub Status: 0xC000006A
Process Information:
Caller Process ID: 0x140
Caller Process Name: C:\Windows\System32\svchost.exe
Network Information:
Workstation Name: -
Source Network Address: -
Source Port: -
Detailed Authentication Information:
Logon Process: CHAP
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Transited Services: -
Package Name (NTLM only): -
Key Length: 0
This event is generated when a logon request fails. It is generated on the computer where access was attempted.
The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.
The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).
The Process Information fields indicate which account and process on the system requested the logon.
The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.
The authentication information fields provide detailed information about this specific logon request.
- Transited services indicate which intermediate services have participated in this logon request.
- Package name indicates which sub-protocol was used among the NTLM protocols.
- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.
Danke und Gruss
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1643981081
Url: https://administrator.de/contentid/1643981081
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
12 Kommentare
Neuester Kommentar
Servus,
evtl. kann das bei der Ursachenforschung hilfreich sein:
https://www.netwrix.de/account_lockout_examiner.html
evtl. kann das bei der Ursachenforschung hilfreich sein:
https://www.netwrix.de/account_lockout_examiner.html
Moin,
ich nutze immer LockOutStatus von MS.
Dort trägt man den Benutzer ein und sieht die TimeStamps, wann es geknallt hat.
TimeStamps merken und im Eventlog aufm DC im Security-Tab vergleichen. Dort sollte stehen, was versucht hat sich anzumelden.
Überleg stark, wo überall der Domänenbenutzer genutzt wird. Wir melden Outlook ab, separat noch MS Teams und sonstige Software, welche den Domänenbenutzer nutzt.
ich nutze immer LockOutStatus von MS.
Dort trägt man den Benutzer ein und sieht die TimeStamps, wann es geknallt hat.
TimeStamps merken und im Eventlog aufm DC im Security-Tab vergleichen. Dort sollte stehen, was versucht hat sich anzumelden.
Überleg stark, wo überall der Domänenbenutzer genutzt wird. Wir melden Outlook ab, separat noch MS Teams und sonstige Software, welche den Domänenbenutzer nutzt.
Zitat von @yoface:
Servus,
danke für eure Tips. Ich habe beide Tools schon ausprobiert und sehe auch die Einträge im Eventlog, aber es zeigt nicht eindeutig von wo die locks kommen..
Daher bleibt mir nur noch den User neu erstellen
Servus,
danke für eure Tips. Ich habe beide Tools schon ausprobiert und sehe auch die Einträge im Eventlog, aber es zeigt nicht eindeutig von wo die locks kommen..
Daher bleibt mir nur noch den User neu erstellen
Ah noch was.
Der Log kommt mir bekannt vor. Hatte die selbe Situation, wo als einziger Hinweis der selbe Log kam. Aber nicht woher und/oder wieso sich das Konto sperrt.
Letztendlich war, warum auch immer, ein Server im Internet erreichbar und es hat einer mittels BruteForce versucht, sich mit dem Konto (vergebens) anzumelden. Ich habe daraufhin die Lücke in der FW geschlossen und dann war auch Ruhe. Gab aber tatsächlich kaum ein Anzeichen, bin mittels der AV-Software drübergestolpert.
Moin
Gruß
Doskias
Zitat von @yoface:
ich habe ein Problem mit einem AD User, welcher alle 10 Minuten im AD gesperrt wird.
Wir haben in der Firma eine neue Passwort Policy aktiviert und ca. 100 Mitarbeiter mussten ihr Passwort ändern.
Klingt als würde irgendwo ein geplanter Task oder eine andere Aufgabe diesen Account nutzen.ich habe ein Problem mit einem AD User, welcher alle 10 Minuten im AD gesperrt wird.
Wir haben in der Firma eine neue Passwort Policy aktiviert und ca. 100 Mitarbeiter mussten ihr Passwort ändern.
Bei 3 Benutzern gab es das Problem das ihr Account immer zu sporadischen Zeiten im AD gesperrt wurde.
Gab heißt du hast es gelöst.Bei 2 Usern konnten wir das Laptop wechseln und seit dem gibt es bei diesen zwei Benutzern keine AD Locks mehr.
Klingt immer noch nach einem geplanten Task auf dem Laptop Nur bei einem Benutzer hat das leider nicht geholfen und sein Account wird immer gesperrt nach ca. 10 Minuten.
Habt ihr hier das Notebook auch gewechselt?Auch läuft ein Azure AD Sync, welcher die on-premise AD Daten in die Azure AD synced. Den Dienst haben wir auch gestoppt und am Azure AD Sync liegt es auch nicht.
Kannst du wieder anmachen. Der Sync läuft deiner Beschreibung nach ja von eurem AD zum Azure-Ad. Dabei wird kein Konto gesperrt.Jetzt können wir als letzte Instanz nur noch sein AD Account neu anlegen und das Exchange Postfach dem neuen Benutzer zu weisen.
Löst aber den Fehler nicht.Weiss jemand wie dazu der beste Weg ist? Sollte man erst ein Clone von seinem AD Benutzer machen und anschliessend den bestehenden löschen und dann alles auf den AD Clone Account umbennen und wieder richtig stellen?
Nein auf keinen Fall. Wenn du den User klonst, dann bekommt er eine neue S-ID. Die ändert sich nicht beim umbenennen. Alle MS-Dienste (Dateifreigaben, Mail-Account, etc.) nutzen die S-ID. auch wenn der User hinterher gleich heißt, hat er eine neue S-ID, die du bei allen AD-Gruppen neu einrichten musst.Oder gibt es dafür sogar irgend eine Anleitung im Netz? Ich will halt nichts falsch machen, da es sich um den Account eines Geschäftsführers handelt.
Dann löse das Problem mit der Kontosperrung. In den Eventlogs vom AD Server sieht man immer folgende Meldung wenn sein Account gesperrt wird:
Such mal nach der Event-ID 4740 in den AD-Protokollen. Dort steht drin, von welchem Rechner die Sperrung erfolgt ist. Ein Paar Einträge früher wirst du noch weitere Informationen finden können.Gruß
Doskias
Moin,
Nicht, dass er mal ein altes iPhone für seine Tochter oder wen auch immer verwendet hat, aber nichts zurücksetzte...
Ich würde mal auf dem Exchange schauen, welche ActiveSync-Clients noch hinterlegt sind.
Gruß
em-pie
Die Benutzer haben noch Smartphones auf dem der Exchange Account eingehängt ist, aber das haben wir auch entfernt und offline genommen, an dem hat es nicht gelegen.
und es ist das einzige Smartphone, welches die betroffene User hat?Nicht, dass er mal ein altes iPhone für seine Tochter oder wen auch immer verwendet hat, aber nichts zurücksetzte...
Ich würde mal auf dem Exchange schauen, welche ActiveSync-Clients noch hinterlegt sind.
Gruß
em-pie
Schau nochmal nach. Das kann nicht sein
Zitat aus: https://docs.microsoft.com/de-de/windows/security/threat-protection/audi ...
Bedeutet: hast du keine 4740, dann hast du auch kein gesperrtes Konto. Kann natürlich sein, dass dein Protokoll so voll ist, dass der Eintrag schon wieder gelöscht wurde. In dem Fall: Protokoll nicht löschen, sondern archivieren.
Gruß
Doskias
Zitat aus: https://docs.microsoft.com/de-de/windows/security/threat-protection/audi ...
Dieses Ereignis wird jedes Mal generiert, wenn ein Benutzerkonto gesperrt ist.
Bei Benutzerkonten wird dieses Ereignis auf Domänencontrollern, Mitgliedsservern und Arbeitsstationen generiert.
Bei Benutzerkonten wird dieses Ereignis auf Domänencontrollern, Mitgliedsservern und Arbeitsstationen generiert.
Bedeutet: hast du keine 4740, dann hast du auch kein gesperrtes Konto. Kann natürlich sein, dass dein Protokoll so voll ist, dass der Eintrag schon wieder gelöscht wurde. In dem Fall: Protokoll nicht löschen, sondern archivieren.
Gruß
Doskias
Zitat von @yoface:
Servus,
danke für eure Tips. Ich habe beide Tools schon ausprobiert und sehe auch die Einträge im Eventlog, aber es zeigt nicht eindeutig von wo die locks kommen..
Daher bleibt mir nur noch den User neu erstellen
Servus,
danke für eure Tips. Ich habe beide Tools schon ausprobiert und sehe auch die Einträge im Eventlog, aber es zeigt nicht eindeutig von wo die locks kommen..
Daher bleibt mir nur noch den User neu erstellen
Wenn Du lange genug in einen Abgrund blickst, blickt der Abgrund auch in Dich hinein.
Schalte die Debugprotokollierung des Netlogon-Dienstes auf allen DCs an
https://docs.microsoft.com/de-de/troubleshoot/windows-client/windows-sec ...
Dann suchst Du darin nach dem Nutzer und wann genau der Fehlercode aufläuft.
Dann hast Du den Verursacher.
Alternativ:
Ändere den Loginnamen. Reicht aus, um das zu beenden.
HI,
hatten den Fehler auch mal und letztlich war es einer der drei AD-Server. Geholfen hat unser dieses Powershell-Script:
hatten den Fehler auch mal und letztlich war es einer der drei AD-Server. Geholfen hat unser dieses Powershell-Script:
#Requires -Version 2.0
Function Get-LockedOutLocation
{
<#
.SYNOPSIS
This function will locate the computer that processed a failed user logon attempt which caused the user account to become locked out.
.DESCRIPTION
This function will locate the computer that processed a failed user logon attempt which caused the user account to become locked out.
The locked out location is found by querying the PDC Emulator for locked out events (4740).
The function will display the BadPasswordTime attribute on all of the domain controllers to add in further troubleshooting.
.EXAMPLE
PS C:\>Get-LockedOutLocation -Identity "SchulzK"
This example will find the locked out location for Joe Davis.
.NOTE
This function is only compatible with an environment where the domain controller with the PDCe role to be running Windows Server 2008 SP2 and up.
The script is also dependent the ActiveDirectory PowerShell module, which requires the AD Web services to be running on at least one domain controller.
Author:Jason Walker
Last Modified: 3/20/2013
#>
[CmdletBinding()]
Param(
[Parameter(Mandatory=$True)]
[String]$Identity
)
Begin
{
$DCCounter = 0
$LockedOutStats = @()
Try
{
Import-Module ActiveDirectory -ErrorAction Stop
}
Catch
{
Write-Warning $_
Break
}
}#end begin
Process
{
#Get all domain controllers in domain
$DomainControllers = Get-ADDomainController -Filter *
$PDCEmulator = ($DomainControllers | Where-Object {$_.OperationMasterRoles -contains "PDCEmulator"})
Write-Verbose "Finding the domain controllers in the domain"
Foreach($DC in $DomainControllers)
{
$DCCounter++
Write-Progress -Activity "Contacting DCs for lockout info" -Status "Querying $($DC.Hostname)" -PercentComplete (($DCCounter/$DomainControllers.Count) * 100)
Try
{
$UserInfo = Get-ADUser -Identity $Identity -Server $DC.Hostname -Properties AccountLockoutTime,LastBadPasswordAttempt,BadPwdCount,LockedOut -ErrorAction Stop
}
Catch
{
Write-Warning $_
Continue
}
If($UserInfo.LastBadPasswordAttempt)
{
$LockedOutStats += New-Object -TypeName PSObject -Property @{
Name = $UserInfo.SamAccountName
SID = $UserInfo.SID.Value
LockedOut = $UserInfo.LockedOut
BadPwdCount = $UserInfo.BadPwdCount
BadPasswordTime = $UserInfo.BadPasswordTime
DomainController = $DC.Hostname
AccountLockoutTime = $UserInfo.AccountLockoutTime
LastBadPasswordAttempt = ($UserInfo.LastBadPasswordAttempt).ToLocalTime()
}
}#end if
}#end foreach DCs
$LockedOutStats | Format-Table -Property Name,LockedOut,DomainController,BadPwdCount,AccountLockoutTime,LastBadPasswordAttempt -AutoSize
#Get User Info
Try
{
Write-Verbose "Querying event log on $($PDCEmulator.HostName)"
$LockedOutEvents = Get-WinEvent -ComputerName $PDCEmulator.HostName -FilterHashtable @{LogName='Security';Id=4740} -ErrorAction Stop | Sort-Object -Property TimeCreated -Descending
}
Catch
{
Write-Warning $_
Continue
}#end catch
Foreach($Event in $LockedOutEvents)
{
If($Event | Where {$_.Properties[2].value -match $UserInfo.SID.Value})
{
$Event | Select-Object -Property @(
@{Label = 'User'; Expression = {$_.Properties.Value}}
@{Label = 'DomainController'; Expression = {$_.MachineName}}
@{Label = 'EventId'; Expression = {$_.Id}}
@{Label = 'LockedOutTimeStamp'; Expression = {$_.TimeCreated}}
@{Label = 'Message'; Expression = {$_.Message -split "`r" | Select -First 1}}
@{Label = 'LockedOutLocation'; Expression = {$_.Properties[1].Value}}
)
}#end ifevent
}#end foreach lockedout event
}#end process
}#end function
Weiss nicht mehr woher, wahrscheinlich Powershell Team, aber der Autor hat diese Webseite :
https://automationjason.wordpress.com/2011/08/27/get-lockedoutlocation-2 ...
https://automationjason.wordpress.com/2011/08/27/get-lockedoutlocation-2 ...