Account lockouts and password policy

Establish the account and effective policy

From an AD PowerShell session:

Search-ADAccount -LockedOut -UsersOnly
Get-ADDefaultDomainPasswordPolicy -Identity contoso.com
Get-ADUserResultantPasswordPolicy -Identity alice

The default domain policy is not always the policy applying to a particular user. If the resultant-password-policy command returns a password settings object (PSO), inspect that object’s lockout threshold, observation window, and duration. If no fine-grained policy applies, use the domain’s default policy.

Get-ADFineGrainedPasswordPolicy -Filter * |
    Select-Object Name, Precedence, LockoutThreshold,
        LockoutObservationWindow, LockoutDuration

Fine-grained policies apply to users and global security groups, rather than being linked to an OU like a GPO. Direct user assignments take precedence over policies obtained through group membership; lower precedence numbers win within the applicable set. Use the resultant-policy command to settle the actual result instead of guessing from group names.

If two applicable policies have the same precedence, the resultant-PSO algorithm breaks the tie using objectGUID, with the smaller value first. Avoid ties in a maintained design, but do not assume display name or creation date chooses the winner. Query the affected user against the DC involved in the failure; a recently edited policy or group membership may not yet have converged. The resultant-PSO algorithm defines these rules.

Compare the GPO with the stored domain policy

The domain object holds the effective default policy attributes. Seeing Not Defined in the GPO editor doesn’t mean an old value has disappeared. Security settings can persist after the policy stops defining them; Microsoft describes this persistence behavior. Check what’s stored in the directory as well as what the GPO is meant to apply.

To compare both views on one DC:

$dc = 'dc1.contoso.com'
$domain = Get-ADDomain -Server $dc
Get-ADDefaultDomainPasswordPolicy -Identity $domain.DistinguishedName `
    -Server $dc | Select-Object MinPasswordAge,MaxPasswordAge,
        MinPasswordLength,PasswordHistoryCount,ComplexityEnabled,
        ReversibleEncryptionEnabled,LockoutThreshold,
        LockoutDuration,LockoutObservationWindow

Get-ADObject -Identity $domain.DistinguishedName -Server $dc `
    -Properties minPwdAge,maxPwdAge,minPwdLength,pwdHistoryLength,
        pwdProperties,lockoutThreshold,lockoutDuration,
        lockOutObservationWindow |
    Select-Object DistinguishedName,minPwdAge,maxPwdAge,minPwdLength,
        pwdHistoryLength,pwdProperties,lockoutThreshold,lockoutDuration,
        lockOutObservationWindow

The first view interprets the policy; the second exposes its LDAP attributes. Raw duration values are directory interval representations, not ordinary positive minute counts. Microsoft’s default-domain policy parameter documentation maps the friendly properties to these attributes. This domain default still does not replace a user’s applicable PSO.

Keep threshold, observation window and lockout duration separate. A zero threshold disables account lockout, while zero lockout duration means an administrator must unlock a locked account. An application may submit several authentication attempts for one visible user action, so a threshold is not a count of clicks. Microsoft’s threshold guidance describes this retry effect and the denial-of-service tradeoff.

Collect the lockout event

The PDC emulator is a useful starting point, although the investigation may need events from other DCs and the accepting server too:

$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'
    Id = 4740
    StartTime = (Get-Date).AddHours(-4)
} | Select-Object TimeCreated, MachineName, Id, Message

Reading remote Security logs requires suitable rights, Event Log connectivity, and the relevant audit policy. An empty query can mean there were no retained events, the wrong DC or time range was searched, or auditing was missing. It does not prove the account was never locked out.

Record the target account, caller computer, event time, and logging DC. A blank caller field needs further correlation. Event 4740 is not a guarantee of the original client’s IP address.

Parse named XML fields rather than relying on translated message text or positional field indexes. For example, this collects one DC’s events into review objects:

$events = Get-WinEvent -ComputerName $pdc -FilterHashtable @{
    LogName = 'Security'; Id = 4740
    StartTime = (Get-Date).AddHours(-4)
}
$events | ForEach-Object {
    [xml]$xml = $_.ToXml()
    $fields = @{}
    foreach ($item in $xml.Event.EventData.Data) {
        $fields[[string]$item.Name] = [string]$item.'#text'
    }
    [pscustomobject]@{
        TimeUtc = $_.TimeCreated.ToUniversalTime()
        DC = $_.MachineName
        RecordId = $_.RecordId
        User = $fields['TargetUserName']
        UserSid = $fields['TargetSid']
        Caller = $fields['CallerComputerName']
    }
}

Keep the original event and account SID, especially if accounts can be renamed. The 4740 event definition describes the subject, target, and caller separately.

Correlate the failure that led to it

Use Microsoft’s AD event list as a reference. Check the status fields: a failed attempt after lockout is different from the bad-password attempts that caused it.

Follow the caller to the workload. Common sources include scheduled tasks, services, saved credentials, mapped drives, disconnected sessions, and applications with their own stored password. A user saying they are “not logging in” does not rule out these background attempts. Offline cached interactive sign-in is also different from an application repeatedly submitting an old password to a DC.

Compare DC state deliberately

Get-ADUser -Identity alice -Server dc1.contoso.com `
    -Properties LockedOut, lockoutTime, badPwdCount, LastBadPasswordAttempt |
    Select-Object SamAccountName, LockedOut, lockoutTime,
        badPwdCount, LastBadPasswordAttempt

Some counters and timestamps belong to the queried DC. They aren’t a combined domain history. Keep the server names and collection times so differences between DCs remain visible.

In particular, badPwdCount and badPasswordTime aren’t replicated. Successful authentication and the lockout observation window also affect what a counter tells you later. Don’t read its current value as the number of attempts a person made during the incident. Microsoft’s badPwdCount definition documents how it is maintained and reset.

The PDC matters because password changes are preferentially replicated to it and another DC can consult it before rejecting a password that looks wrong locally. This can distinguish a recently changed password from a genuinely bad one; Microsoft’s PDC role description documents that path. Successful authentication at a non-PDC can also trigger a best-effort request to reset the PDC’s bad-password count. The MS-SAMS reset rule explicitly permits that request to fail without failing the successful logon. This is another reason current counters are state, not a complete event ledger.

Distinguish a bad password from the consequence of lockout

An NTLM validation status 0xC000006A indicates a wrong password; 0xC0000234 indicates an already locked account. For Kerberos preauthentication, failure 0x18 is invalid preauthentication information, commonly a wrong password, while 0x12 is revoked client credentials and requires account-state investigation. Do not count every post-lockout rejection as another wrong-password attempt that caused the original lockout. Use the 4776 status table and 4771 failure table.

The caller can be a web server or gateway sitting between the client and DC. Match its application logs to the DC event time and follow the connection back. An application using a stored password may keep trying after its owner has logged off. A regular interval suggests a task or retry loop, but check the process or application before settling on that explanation.

Also check whether authentication traffic is timing out in a secure-channel queue. A prompt or access-denied message is not by itself evidence of a wrong password. See NTLM bottlenecks.

Unlock after finding the source

Directory change: once the caller and cause have been addressed, an authorised administrator can unlock the account:

Unlock-ADAccount -Identity alice -Confirm

Watch the next authentication attempts and confirm the account stays usable. Repeatedly unlocking it without stopping the old-password source obscures the investigation and can keep the user in a loop.

For fine-grained policy changes, test with an account representing the real group memberships. An administrator changing the default policy while the affected user has a PSO may change the wrong setting entirely.