Detecting the source of locked AD accounts
Informational summary
Incorrect password attempts exceeding the account lockout threshold in a domain results in the user account being locked out, with event ID 4740 recorded in the Security log of domain controllers. If audit logging is enabled on client computers, event ID 4625 is also recorded. The event log provides valuable information like user account name, domain controller name, source computer name, timestamp, etc. For large AD environments, querying domain controllers first to find the source computer's details is more practical than querying all client computers.
Expand the Security Log size
Increasing the Security log size on a domain controller is recommended for large AD environments. The default size is 128 MB, leading to automatic overwriting of old events when full. To identify account lockout sources, adjust the log size through modifying the default domain controller policy.
Audit logging enabled.
Enable audit logging on domain controllers by modifying the default domain controller policy as follows:
- Log on to any domain controller and launch the Group Policy ManageConsole gpmc.msc
- Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Management.
- Now enable the Audit User Account Management subcategory for Success and Failure, as shown in the screenshot below:
If event ID 4740 is missing on domain controllers, Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Account Logon.
Event ID 4771 shows source IP of failed Kerberos authentication with pre-authentication failure.
Audit logging enabled.
Modify domain policy for audit logging on clients.
- Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff.
- Now enable Audit Account Lockout, Audit Logoff, Audit Logon, and Audit Other Logon/Logoff Events, as shown in the following screenshot:
Detecting lockout
Auditing is enabled on domain controllers and client computers. Account lockouts are processed on the PDC emulator role holder. Use PowerShell command to determine the PDC role holder in the domain.
(Get-ADDomain).PDCEmulator
Get events using PowerShell code snippet:
# Getting the PDC emulator DC
$pdc = (Get-ADDomain).PDCEmulator
# Creating filter criteria for events
$filterHash = @{LogName = "Security"; Id = 4740; StartTime = (Get-Date).AddDays(-1)}
# Getting lockout events from the PDC emulator
$lockoutEvents = Get-WinEvent -ComputerName $pdc -FilterHashTable $filterHash -ErrorAction SilentlyContinue
# Building output based on advanced properties
$lockoutEvents | Select @{Name = "LockedUser"; Expression = {$_.Properties[0].Value}}, `
@{Name = "SourceComputer"; Expression = {$_.Properties[1].Value}}, `
@{Name = "DomainController"; Expression = {$_.Properties[4].Value}}, TimeCreated
Filter criteria were set to search for event ID 4740 in the Security log within the last 24 hours. Get-WinEvent cmdlet was utilized to extract logs based on the filter hash. Calculated properties were used to generate output with locked-out user name, source computer name, DC name, and timestamp of the event creation. More details on these properties will be provided later.
Query source computer for events with ID 4625 to identify process causing account lockout. Review updated code snippet:
# Creating filter criteria for events
$filterHash = @{LogName = "Security"; Id = 4625; StartTime = (Get-Date).AddDays(-1)}
# Getting lockout events from the source computer
$lockoutEvents = Get-WinEvent -ComputerName WRK-NODE0051 -FilterHashTable $filterHash -MaxEvents 1 -ErrorAction 0
# Building output based on advanced properties
$lockoutEvents | Select @{Name = "LockedUserName"; Expression = {$_.Properties[5].Value}}, `
@{Name = "LogonType"; Expression = {$_.Properties[10].Value}}, `
@{Name = "LogonProcessName"; Expression = {$_.Properties[11].Value}}, `
@{Name = "ProcessName"; Expression = {$_.Properties[18].Value}}
The screenshot displays LogonProcessName as User32, ProcessName as svchost.exe, and LogonType as 2, indicating an interactive logon attempt. The user entered a wrong password, resulting in the account being locked out. LogonType field has various possible values
Logon Type Title Description
2 Interactive An interactive logon to a local computer.
3 Network A logon from the network to a local computer.
4 Batch A batch logon type means a process is executed on behalf of a user account.
5 Service A service was started by a service control manager.
7 Unlock A local workstation is unlocked.
8 NetworkCleartext A user logged on to a local computer from the network, and the password was passed in cleartext.
9 NewCredentials A cloned token was used so the new session has the same user identity locally but uses a different credential for remote network connections. This logon type is recorded when you use RunAs with the /netonly switch.
10 RemoteInteractive A user was logged on using Remote Desktop or Terminal Services.
11 CachedInteractive A user was logged on using cached credentials without contacting the domain controller to verify credentials.
The LogonType field helps identify the cause of account lockouts. The properties used to create the output are defined in the security auditing XML template of event logs. To access these properties, use a specific command.
((Get-WinEvent -ListProvider "Microsoft-Windows-Security-Auditing").events | Where -Property ID -eq 4625).template
Properties of XML template in event logs understanding.
The Get-WinEvent cmdlet in the snippet stored properties in an array and accessed them by index number. For instance, to retrieve the target username from the event log property, {$_.properties[5].value} was used as it was at index 5. Similarly, for logon type, {$_.properties[10].value} was used. This method was also applied to event ID
Thanks to: Surender Kumar/4sysops