Find the source of Active Directory account lockouts

Repeated lockouts almost always come from a device or service still using the user’s old password after a password change. The domain controllers record which computer sent the bad password; this guide shows how to read it.

Symptoms

• A user is locked out again minutes after being unlocked.
• Lockouts started right after a password change.
• Get-ADUser shows a climbing BadLogonCount.

Cause

Usual suspects, roughly in order:

• A phone or tablet with the old password saved for email or Wi-Fi.
• A mapped drive or Windows Credential Manager entry with old credentials.
• A disconnected RDP session still signed in on another server.
• A service or scheduled task running as the user’s account.
• Apps such as Outlook, Teams or a VPN client on a second PC.

Fix

Run these from a machine with the RSAT Active Directory PowerShell module, as a domain admin.

1. Confirm the lockout and see which DCs saw bad passwords

$user = 'jsmith'
Get-ADUser $user -Properties LockedOut, BadLogonCount, LastBadPasswordAttempt |
  Select-Object Name, LockedOut, BadLogonCount, LastBadPasswordAttempt

Get-ADDomainController -Filter * | ForEach-Object {
  $u = Get-ADUser $user -Server $_.HostName -Properties BadPwdCount, LastBadPasswordAttempt
  [pscustomobject]@{ DC = $_.HostName; BadPwdCount = $u.BadPwdCount; LastBadPassword = $u.LastBadPasswordAttempt }
} | Format-Table

2. Read event 4740 on the PDC emulator

Bad-password attempts are forwarded to the PDC emulator, which logs event ID 4740 (“A user account was locked out”). This event doesn’t replicate, so query the PDC emulator first, then the other DCs if you find nothing.

$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{ LogName = 'Security'; Id = 4740 } -MaxEvents 50 |
  Select-Object TimeCreated,
    @{ n = 'User';           e = { $_.Properties[0].Value } },
    @{ n = 'CallerComputer'; e = { $_.Properties[1].Value } } |
  Where-Object User -eq $user

CallerComputer is the device sending the bad password.

3. Fix the source

On the caller computer, look for the old password:

• Credential Manager (Control Panel › Credential Manager › Windows Credentials)
• mapped drives (net use)
• services and scheduled tasks running as the user
• logged-on sessions (quser /server:NAME)

If the caller is a mail or VPN server, the source is usually a phone or a remote PC; check that server’s logs for the client IP.

4. Unlock the account

Unlock-ADAccount -Identity $user

If that didn’t work

• CallerComputer is blank: the request came through NTLM from a non-Windows device or an app. On the DCs, check event 4771 (Kerberos pre-authentication failed), which includes the client IP address. Check event 4625 on member servers.
• No 4740 events at all: make sure the Audit User Account Management policy (Success) is enabled for domain controllers in the Default Domain Controllers Policy.
• Still nothing: enable Netlogon debug logging on the PDC emulator with nltest /dbflag:0x2080ffff, reproduce the lockout, and read %windir%\debug\netlogon.log. Turn logging back off afterward with nltest /dbflag:0x0.

When to call us

• Lockouts affect many accounts at once: that pattern can mean a password-spray attack.
• The source is an internet-facing server: RDP, VPN or Outlook on the web.
• You’d like lockout alerts sent to you automatically through our monitoring.