Active Directory Account Keeps Locking Out? Find the Source with Event ID 4740

When a user calls and says their account is locked again, unlocking it is the easy part. If the source is not found, the account locks out again a few minutes later. In most cases the cause is not the user typing a wrong password, but an old password stored somewhere: a saved credential, a mapped drive, a service, a scheduled task or a forgotten session.

In this guide I go through the order I use to find the source of a recurring lockout with Event ID 4740 and PowerShell.

The problem

The account is unlocked, the user may even change the password, and shortly afterwards the account is locked again. Unlocking repeatedly only treats the symptom. The goal is to find the device or process that keeps sending the wrong password.

Prerequisites

• A user with permission to read the Security log on Domain Controllers
• The Active Directory PowerShell module (RSAT)
• An audit policy that records account lockout events (Audit User Account Management)

1. Confirm the lockout

First I check that the account really is locked and look at the bad password information:

Search-ADAccount -LockedOut -UsersOnly

Get-ADUser -Identity username -Properties LockedOut,BadPwdCount,LastBadPasswordAttempt |
    Select-Object Name,SamAccountName,LockedOut,BadPwdCount,LastBadPasswordAttempt

username is a placeholder; use the account’s SamAccountName. BadPwdCount and LastBadPasswordAttempt are kept per Domain Controller, so the values can differ between DCs.

2. Find Event ID 4740 in Event Viewer

Event ID 4740 is written to the Security log of the Domain Controller that processed the lockout, which is usually the PDC Emulator. In Event Viewer I open Windows Logs → Security and filter for 4740. In the event I look at three fields:

• Account Name: the locked account
• Caller Computer Name: the computer the failed attempts came from
• Time Created: when the lockout happened

Caller Computer Name is the most important field, because it tells me where to look next.

3. Query Event ID 4740 with PowerShell

On a Domain Controller I list the latest lockout events:

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 50 |
    Select-Object TimeCreated,
        @{Name='User';Expression={$_.Properties[0].Value}},
        @{Name='CallerComputer';Expression={$_.Properties[1].Value}}

To see only one user:

$User = 'username'
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 200 |
    Where-Object { $_.Properties[0].Value -eq $User } |
    Select-Object TimeCreated,
        @{Name='CallerComputer';Expression={$_.Properties[1].Value}}

If the same Caller Computer Name keeps appearing at regular intervals, that usually points to an automated process rather than the user.

4. Inspect the source computer

Once I know the computer, I check the places where an old password is typically stored:

• Credential Manager: saved Windows and generic credentials
• Mapped drives connected with stored credentials
• Services running under the user account
• Scheduled tasks running under the user account
• VPN and RDP connections with saved passwords
• Applications that keep their own login (mail clients, sync tools)
• Old sessions: disconnected RDP sessions on servers

Scheduled tasks running under the account:

Get-ScheduledTask | Where-Object { $_.Principal.UserId -match 'username' } |
    Select-Object TaskName,TaskPath,State

Services running under the account:

Get-CimInstance Win32_Service | Where-Object { $_.StartName -match 'username' } |
    Select-Object Name,StartName,State

5. Check related events

Event ID 4740 tells me that the account was locked. To understand which authentication failed, I also look at these events:

• 4625: an account failed to log on (on the computer where the logon was attempted)
• 4771: Kerberos pre-authentication failed (on the Domain Controller)
• 4776: the computer attempted to validate the credentials of an account (NTLM)

4771 shows the client IP address of the Kerberos request; 4776 shows the workstation for NTLM. Together they narrow down the source when 4740 alone is not enough.

6. Unlock the account

Only after the source is found and fixed do I unlock the account:

Unlock-ADAccount -Identity username

Unlocking before the source is removed usually means the account is locked again within minutes.

If Caller Computer Name is empty

Sometimes the Caller Computer Name field is empty or contains a name that does not help. In that case I check:

• Events 4771 and 4776 on the Domain Controllers, for the client IP or workstation name
• Servers that authenticate on behalf of users, such as mail, web, VPN or RADIUS servers
• Mobile devices that sync mail with stored credentials

My account lockout checklist

1. Is the account really locked (Search-ADAccount, Get-ADUser)?
2. Is there an Event ID 4740 for the account?
3. What is the Caller Computer Name?
4. Does the same source repeat at regular intervals?
5. Are there saved credentials in Credential Manager?
6. Are there mapped drives with stored credentials?
7. Do any services run under the account?
8. Do any scheduled tasks run under the account?
9. Are there VPN, RDP or application logins with an old password?
10. What do 4625, 4771 and 4776 show?

Security and best practices

• Do not run services or scheduled tasks under personal user accounts; use dedicated service accounts or gMSA.
• Do not weaken the lockout policy just to stop the calls. A recurring lockout can also be a sign of a password-guessing attempt.
• If the source is unknown or outside your network, treat the case as a security event and investigate it.
• Ask users to update saved passwords on all their devices after a password change.

Validation

After removing the source and unlocking the account, I watch the Domain Controller for a while. If no new Event ID 4740 is written for the account and BadPwdCount does not increase again, the source has been found.

Conclusion

A recurring account lockout is rarely solved by unlocking. Event ID 4740 and the Caller Computer Name show where to look; Credential Manager, services, scheduled tasks and old sessions on that computer usually show why. Unlock the account only after the source has been removed.

Related guides

• PowerShell commands (Turkish)
• Windows LAPS in Active Directory: A Step-by-Step Setup Guide
• Event log management with PowerShell (Turkish)
• Exporting Active Directory users to CSV with PowerShell (Turkish)
• Kerberos authentication troubleshooting: klist, SPN and KDC
• Setting a password policy with GPO (Turkish)