Account lockouts in Active Directory environments typically occur when multiple failed authentication attempts hit the threshold defined in your domain password policy. The challenge lies in tracing the source among multiple potential candidates:
- Persistent mapped network drives with stale credentials
- Mobile devices with cached credentials
- Scheduled tasks running under user context
- Service accounts with expired passwords
- Applications storing credentials in configuration files
The most powerful native tool for lockout investigation is the Domain Controller Security Event Log. Look for Event ID 4740 (Account Locked Out) which contains crucial information:
# PowerShell snippet to query lockout events
Get-WinEvent -LogName Security -FilterXPath
'*[System[EventID=4740]]' -MaxEvents 10 |
Format-List -Property TimeCreated,Message
For more detailed tracking, enable Netlogon debugging on your DCs:
# Enable Netlogon logging
nltest /dbflag:0x2080ffff
# Logs will be written to %windir%\debug\netlogon.log
When dealing with intermittent lockouts, consider these approaches:
# Create a real-time lockout monitoring script
$query = @"
SELECT * FROM __InstanceModificationEvent WITHIN 5 WHERE
TargetInstance ISA 'ds_user' AND
TargetInstance.lockoutTime <> PreviousInstance.lockoutTime
"@
Register-WMIEvent -Query $query -Action {
$user = $event.SourceEventArgs.NewEvent.TargetInstance
Write-Host "Lockout detected for $($user.name) at $(Get-Date)"
}
Based on field experience, these are frequent causes:
Source | Detection Method | Remediation |
---|---|---|
Outlook/Exchange | Check IIS logs on CAS servers | Clear OST files, update credentials |
Mobile Devices | Review RADIUS/NPS logs | Wipe device or update credentials |
Service Accounts | Audit service configurations | Implement managed service accounts |
Implement these strategies to reduce lockout incidents:
- Configure fine-grained password policies for service accounts
- Implement Account Lockout Threshold exceptions for specific applications
- Deploy self-service password reset solutions
# Sample fine-grained password policy
New-ADFineGrainedPasswordPolicy -Name "ServiceAccountPolicy"
-Description "Policy for service accounts"
-Precedence 100 -LockoutDuration "00:30:00"
-LockoutObservationWindow "00:30:00"
-LockoutThreshold 15 -AppliesTo "CN=ServiceAccounts,OU=Special,DC=domain,DC=com"
For critical environments, consider building an automated response system:
# Basic automated unlock script
$lockedUsers = Search-ADAccount -LockedOut |
Where {$_.SamAccountName -ne "Administrator"}
foreach ($user in $lockedUsers) {
Unlock-ADAccount -Identity $user.SamAccountName
Send-MailMessage -To "support@domain.com"
-From "noreply@domain.com" -Subject "Auto-unlocked $($user.SamAccountName)"
-Body "Account was automatically unlocked after detection"
-SmtpServer "mail.domain.com"
}
Account lockouts in Active Directory environments often feel like IT whodunits - you know the victim (the locked account) but need forensic evidence to identify the perpetrator (the service/machine causing it). Here's how to investigate systematically without third-party tools.
First, ensure proper auditing is enabled on domain controllers:
# PowerShell to enable account lockout auditing
Set-GPOAuditPolicy -Path "DC=domain,DC=com" -AuditPolicy @{
"Account Lockout" = "Success"
}
On your domain controllers, search for Event ID 4740 (account lockout) in Security logs. The key fields to examine are:
- Caller Computer Name - The machine where the bad password originated
- Target Account Name - The locked user account
- Source Workstation - Especially important for older authentication protocols
Example log query:
# PowerShell to find lockout events
Get-WinEvent -LogName Security -FilterXPath "*[System[EventID=4740]]" |
Select-Object -Property TimeCreated,
@{Name='User';Expression={$_.Properties[0].Value}},
@{Name='CallerComputer';Expression={$_.Properties[1].Value}}
When you identify the source machine, check these common lockout culprits:
:: Batch script to check common lockout sources
@echo off
REM Check mapped drives
net use
REM Check scheduled tasks
schtasks /query /fo LIST /v
REM Check services running as user
sc query | findstr /i "SERVICE_NAME"
wmic service get name,startname | findstr /i "DOMAIN\\username"
REM Check credential manager
cmdkey /list
These services frequently cause lockouts:
- Outlook caching old credentials (especially in OST files)
- Mobile devices with incorrect Exchange ActiveSync settings
- SQL linked servers or jobs
- Service accounts with expired passwords
- Cached RDP credentials on multiple workstations
To reduce lockout impact without disabling the policy:
# ADSI edit to implement lockout threshold
$domain = [ADSI]"LDAP://DC=domain,DC=com"
$domain.psbase.InvokeSet("lockoutThreshold", 10) # Increase from default 5
$domain.psbase.CommitChanges()
Create a simple monitoring script that emails alerts when lockouts occur:
# PowerShell lockout monitor
$query = @"
<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[EventID=4740]]</Select>
</Query>
</QueryList>
"@
Register-WinEvent -Query $query -Action {
$event = $EventArgs.NewEvent
$body = "Account $($event.Properties[0].Value) locked out from $($event.Properties[1].Value)"
Send-MailMessage -To "admin@domain.com" -Subject "AD Lockout Alert" -Body $body -SmtpServer "smtp.domain.com"
}