How to fix "the referenced account is currently locked out" error

You've seen the message: "the referenced account is currently locked out and may not be logged on to." It means a Windows account hit the failed logon attempt limit and got temporarily locked. The threshold is defined in the domain's account lockout policy, and once triggered, the lockout replicates across all domain controllers.

Sometimes it's just a forgotten password. Sometimes it's something hammering your environment with bad credentials at two in the morning while nobody's watching. Either way, you need to unlock the account fast, then figure out why it happened so it stops happening.

This guide covers the common causes, how to unlock the account in both domain and local environments, how to trace the lockout source using Event ID 4740, and how to keep it from recurring.

What causes "the referenced account is currently locked out"

Windows locks an account when consecutive failed logon attempts reach the value configured in the Account lockout threshold policy. You'll find this under Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy, alongside the lockout duration and reset counter settings.

Here's what typically triggers the error:

Repeated incorrect password entry. Someone types the wrong password too many times. Straightforward, and usually the first thing people assume.

Stale credentials in Windows services or scheduled tasks. After a password change, any service or scheduled task still running under the old credentials fails authentication against the domain controller. Each failure counts toward the lockout threshold. This one catches people off guard because the service might run once an hour or once a day, quietly racking up failures in the background.

Mobile devices with a cached password. Outlook, Exchange ActiveSync, and other mobile apps authenticating against Active Directory keep sending the old password until someone manually updates it on the device. Your phone doesn't know you changed your password yesterday.

Mapped network drives using saved credentials. If a user has mapped drives that store credentials and the password changes, every reconnection attempt sends the outdated password.

Disconnected RDP sessions. A Remote Desktop session left open on one machine while the user changes their password elsewhere keeps authenticating with the old credentials.

Multiple machines with a previous password. A user logged in on two or more computers who changes their password on one triggers failures from the others.

In a domain environment, the lockout happens at the domain controller level. Once locked, that status replicates across all domain controllers, so the user can't authenticate anywhere until the lockout clears.

How to fix the locked account

For administrators in a domain environment

Unlock via Active Directory Users and Computers

1. Open Active Directory Users and Computers (run dsa.msc).
2. Navigate to the organizational unit (OU) containing the locked account.
3. Right-click the user account and select Properties.
4. Open the Account tab.
5. Check the box labeled Unlock account. You'll see a message indicating the account is currently locked out on a domain controller.
6. Click Apply, then OK. The account unlocks immediately and the user can try logging in again.

Unlock using the command line

From an elevated Command Prompt on a machine with the Active Directory module available, run:

net user <username> /active:yes /domain

Replace <username> with the locked account name.

Or use PowerShell with the Active Directory module:

Unlock-ADAccount -Identity <username>

Both take effect immediately. The PowerShell cmdlet requires the Remote Server Administration Tools (RSAT) Active Directory module.

Check and adjust lockout policy settings

If accounts keep locking out, review your domain's lockout policy. Open the Group Policy Management Console (gpmc.msc) and navigate to:

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Account Lockout Policy

Three settings control lockout behavior:

If the lockout duration is set to zero, only an administrator can unlock the account. A threshold that's too low (two or three attempts) floods your help desk with tickets, while one that's too high weakens brute-force protection. There's no universally correct number; it depends on your environment and risk tolerance.

After changes, run gpupdate /force on target machines to apply the updated policy.

For local (non-domain) machines

Wait for the lockout duration to expire

If you don't have administrative access, the simplest option is to wait. The lockout duration is typically 30 minutes by default, though your administrator may have set a different value.

Check the current setting with an elevated Command Prompt:

net accounts

Look for the Lockout duration (minutes) line.

Unlock via Local Users and Groups (lusrmgr.msc)

1. Log in to the machine with a different local administrator account.
2. Press Win + R, type lusrmgr.msc, and press Enter.
3. Click Users in the left pane.
4. Double-click the locked account.
5. Uncheck Account is locked out and click Apply, then OK.

Unlock using net user (local)

From an elevated Command Prompt:

net user <username> /active:yes

This unlocks the local account immediately.

How to find the lockout source

Unlocking the account fixes the symptom. Finding what's sending the bad credentials fixes the actual problem. Skip this step and the account locks out again, probably at the worst possible time.

Event ID 4740 in the Security event log

Every time an account locks out, Windows logs Event ID 4740 on the domain controller that processed it. The field you care about is Caller Computer Name, which tells you the machine that sent the failed authentication.

To find it:

1. Open Event Viewer on one of your domain controllers (eventvwr.msc).
2. Navigate to Windows Logs > Security.
3. Click Filter Current Log in the right pane. Enter 4740 in the Event ID field and click OK.
4. Review the filtered events and note the Caller Computer Name field.

Once you've identified the source machine, log in to it and look for stale credentials. Check Windows Credential Manager, services running under the locked account, scheduled tasks, and mapped network drives.

Cross-reference with Event ID 4625

Event ID 4625 logs every individual failed logon attempt, including the failure reason and source network address. Filter for 4625 events matching the locked user's account name, around the same time as the 4740 event, to see exactly what type of authentication failure triggered the lockout.

Check the Sub Status code in Event ID 4625 for specifics. A value of 0xC000006A means the password was wrong; 0xC0000064 means the username itself wasn't found.

Security risks of repeated account lockouts

A single lockout from a known internal machine is almost always a stale credential issue. A pattern of lockouts across multiple accounts, from unfamiliar source IPs, or outside business hours? That's a different conversation.

Brute-force attacks. An attacker guesses passwords rapidly against a single account. The lockout threshold stops the attack, but the lockout itself confirms the account exists, giving the attacker reconnaissance data.

Password spray attacks. Instead of hammering one account, the attacker tries one or two common passwords against every account in the domain. Because each account receives only a few attempts, individual thresholds may not trigger. But a coordinated spray across hundreds of accounts produces an unusual volume of lockout events within a short window.

Denial-of-service through intentional lockout. An attacker who knows account names can deliberately trigger lockouts on administrator and service accounts to disrupt operations. If the lockout duration is zero (requiring manual unlock), those accounts stay locked until someone intervenes. I've seen this used as a distraction during more targeted attacks elsewhere in the network.

The MITRE ATT&CK® framework documents these patterns under technique T1110 (Brute Force), with sub-techniques covering password guessing, password spraying, and credential stuffing.

Telling legitimate lockouts apart from attacks comes down to volume, timing, and source diversity. One lockout from an internal workstation at 10 a.m. on a Tuesday is routine. Fifty lockouts from 20 different source IPs at 3 a.m. on a Saturday is not.

ADAudit Plus detects password spray and brute-force attacks through its Attack Surface Analyzer, correlating lockout patterns across the domain to flag coordinated attack attempts in real time.

Native tool limitations for lockout investigation

Event Viewer gives you the raw data, but investigating lockouts at scale with native tools alone gets old fast.

Event logs are scattered across multiple domain controllers. Event ID 4740 gets logged on the domain controller that processed the lockout, and there's no built-in way to view lockout events from all domain controllers in one place. You have to check each DC individually. That's fine when you have three DCs and miserable when you have 30.

Event Viewer can't correlate events across machines. Connecting Event ID 4740 on one domain controller with Event ID 4625 on another, then tracing the Caller Computer Name to a specific service or process on a third machine, is manual work at every step.

No automated root cause analysis. Finding the Caller Computer Name is only step one. You still have to log in to that machine and manually dig through services, scheduled tasks, Credential Manager, and mapped drives to find what's sending the old password.

Security logs overwrite older events. The Security event log has a fixed size. In busy environments, lockout events from earlier in the week may already be gone by the time you investigate on Monday morning.

No real-time alerting without scripting. Native Windows won't alert you when an account locks out. You can configure Task Scheduler to trigger on Event ID 4740, but building reliable email notifications that way requires custom scripting and ongoing maintenance.

No behavioral baseline for lockout patterns. Native tools can't tell you whether today's lockout volume is normal or abnormal. There's no built-in mechanism to learn what's typical for your environment and flag deviations.

Monitoring account lockouts with ADAudit Plus

What ADAudit Plus monitors for account lockouts

ADAudit Plus pulls lockout data from every domain controller into a single console, replacing the manual, multi-DC investigation that native tools require.

The Account Lockout Analyzer identifies the machine, service, or process that caused the lockout in one click. The report includes the affected user, caller machine, lockout time, domain controller that processed the lockout, analyzer details, caller IP, and the user's logon history leading up to the event.

The Recently Locked Out Users report gives you a consolidated view of every lockout event across all domain controllers. The Recently Unlocked Users report records who unlocked each account and when.

ADAudit Plus supports real-time alert profiles for lockout events. When an account locks out, the system sends an email or SMS notification to the help desk or security team. No custom scripting or Task Scheduler configuration needed.

The user behavior analytics engine uses machine learning to establish a baseline lockout rate for the domain. Unusual Volume of Lockout detection flags abnormal spikes (say, 20 lockouts within five minutes when the daily average is two). Unusual Lockout Activity Time detection catches lockouts occurring outside normal business hours.

The Logon Failures report correlates failed logon attempts with lockout events, letting you trace the failure reason, source IP, and logon type for every bad authentication attempt that contributed to the lockout.

Native tools vs. ADAudit Plus

FAQ