Active Directory account lockout: find the device using an old password

Unlocking does not remove the cause

An account that locks after every password change may be used by a task, service, device, or session retaining an old secret. This is a hypothesis to test, not an automatic diagnosis: malicious attempts can produce the same symptom.

This guide targets Active Directory Domain Services. Local Windows lockout and Microsoft Entra Smart Lockout are separate mechanisms. First identify the account, domain, and service rejecting access.

Prepare a bounded investigation

Record the latest lockout time, time zone, last password change, and devices in use. Maintain a UTC timeline. Query a short interval around the incident instead of every domain log.

Use an administrative workstation with RSAT/ActiveDirectory and AD read access. Reading Security requires effective permission on each machine; do not grant Domain Admin solely for this investigation. Remote collection also depends on firewall and event-log service access. An access error is not an absence of events.

Find the PDC and effective policy

The PDC Emulator is a useful starting point, but it is not a central archive of every domain event. If evidence is incomplete, query the other relevant controllers.

A fine-grained password policy can override the domain policy for this user. Read the threshold, duration, and reset window; do not increase them to hide the problem. Observed state also depends on the queried DC and collection time.

# Read-only; fictional account
Import-Module ActiveDirectory
$pdc = (Get-ADDomain).PDCEmulator
$user = Get-ADUser -Identity 'alice.martin' -Server $pdc -Properties LockedOut,PasswordLastSet
$user | Select-Object SamAccountName,SID,LockedOut,PasswordLastSet
$policy = Get-ADUserResultantPasswordPolicy -Identity $user -Server $pdc
if (-not $policy) { $policy = Get-ADDefaultDomainPasswordPolicy -Server $pdc }
$policy | Select-Object LockoutThreshold,LockoutDuration,LockoutObservationWindow

• Microsoft Learn ↗

Read 4740 without blaming a device too early

Security event 4740 records a lockout. Use the target account SID to avoid ambiguous names. The event subject can be SYSTEM; it does not automatically identify the person who entered the wrong password.

Caller Computer Name is a lead. An intermediary server or blank field does not directly identify the original endpoint. Correlate timestamps and the named server’s logs before changing anything.

# Read-only; run after the preceding block
$start = (Get-Date).AddHours(-2)
$end = Get-Date
Get-WinEvent -ComputerName $pdc -FilterHashtable @{
  LogName='Security'; Id=4740; StartTime=$start; EndTime=$end
} -ErrorAction Stop | ForEach-Object {
  $event = $_
  $data = @{}
  ([xml]$event.ToXml()).Event.EventData.Data | ForEach-Object {
    $data[$_.Name] = $_.'#text'
  }
  if ($data.TargetSid -eq $user.SID.Value) {
    [pscustomobject]@{
      TimeUTC=$event.TimeCreated.ToUniversalTime()
      DC=$event.MachineName; RecordId=$event.RecordId
      Account=$data.TargetUserName; Caller=$data.CallerComputerName
    }
  }
} | Sort-Object TimeUTC

• Microsoft Learn ↗

Correlate Kerberos, NTLM, and logon events

4771 concerns Kerberos preauthentication failures on DCs. Inspect the failure code and client address; not every 4771 means a wrong password.

4776 concerns NTLM validation on the account authority: a DC for a domain account. Its source workstation is not a complete network-path record. Then inspect 4625 on the machine where logon failed; logon type, status, substatus, and process can guide investigation.

Compare events before lockout with those afterward: rejection because an account is already locked does not necessarily explain the original cause. Do not blindly add events from several DCs to reconstruct a lockout counter.

• Microsoft Learn ↗
• Microsoft — 4776 ↗
• Microsoft — 4625 ↗

Inspect the identified machine

On the suspected server or workstation, look for services and tasks running as this account. The following commands read local configuration; run them on the identified machine with the necessary rights. A configured account does not prove it caused the lockout.

Also review disconnected RDP sessions, mapped drives, Credential Manager in the affected session, applications, phones, and VPN/Wi-Fi access. Running cmdkey /list as your administrator account does not inventory every user’s credentials. Do not extract or display secrets.

# Read-only local inventory; fictional identity
$account = 'CONTOSO\alice.martin'
Get-CimInstance Win32_Service | Where-Object StartName -eq $account |
  Select-Object Name,State,StartMode,StartName
Get-ScheduledTask | Where-Object { $_.Principal.UserId -eq $account } |
  Select-Object TaskPath,TaskName,State
# Also check UPN-form identities in the approved inventory.

Example: a task running every fifteen minutes

Alice changes her password at 8:00. Lockouts recur at 8:15 and 8:30. A 4740 points to APP01; local events and Task Scheduler history align with a task running as her account. This correlation makes the task suspicious; confirm with its owner and a controlled test.

If the named server is NPS, RRAS, or a gateway, consult its logs to trace the original client. The gateway name does not justify restarting it. Several accounts affected by an unknown source require security investigation.

Controlled remediation and rollback

Change: after owner approval, correct only the identified stored credential or configuration. For a critical service, schedule a change window and preserve its configuration without exposing the secret. Do not stop all tasks or terminate every session in bulk.

An authorized unlock can follow remediation using Unlock-ADAccount for the single affected account with appropriate delegated rights. This change does not reset the password or remove the source of attempts. Do not implement an automatic unlock loop.

Validate a legitimate sign-in and observe at least the triggering cycle, including the next scheduled job. If a regression occurs, restore the documented configuration and keep the faulty component controlled; restoring an old user password is not a rollback strategy.

• Microsoft Learn ↗

Missing logs and follow-up

Check effective audit policy: User Account Management for 4740, Kerberos Authentication Service for 4771, Credential Validation for 4776, and logon auditing for 4625. Enabling auditing later cannot recreate missing events. Pilot collection changes according to volume and approved retention.

Centralize useful events in WEF or your SIEM. Protect exports and EVTX files, preserve collection times and event identifiers, and avoid screenshots containing internal information in public tickets.

Document the confirmed cause, owner, fix, and monitoring period. For compatible applications, consider a gMSA to reduce manually maintained service secrets. Active Directory consulting can address these dependencies; this targeted diagnosis does not replace a full assessment.