A user swears they typed the right password, yet Microsoft Entra ID says the account is locked. Sometimes it's an attacker spraying passwords, sometimes it's an old phone retrying a stale password, and in hybrid tenants it can be Active Directory doing the locking. In this post I'll explain how smart lockout decides, how to find the source and how to unlock without helping the attacker.
Errors this guide fixes
Your account is temporarily locked to prevent unauthorized use. Try again later, and if you still have trouble, contact your admin.Sign-in pageAADSTS50053 IdsLockedSign-in page / Microsoft Entra sign-in logAADSTS50126: Error validating credentials due to invalid username or password.Sign-in page / Microsoft Entra sign-in log+1 more guideAADSTS50057: The user account is disabled.Sign-in page / Microsoft Entra sign-in logAADSTS50144 InvalidPasswordExpiredOnPremPasswordMicrosoft Entra sign-in logEvent ID 4740: A user account was locked out.Security log (domain controller)
Symptoms#
The sign-in page shows:
Your account is temporarily locked to prevent unauthorized use. Try again later, and if you still have trouble, contact your admin.The sign-in log records error 50053. Related codes are easy to confuse, so check which one you actually have:
| Code | Meaning | Is it a lockout? |
|---|---|---|
AADSTS50053 | AADSTS50053 IdsLocked: too many sign-ins with an incorrect user ID or password, or the sign-in came from an IP address with malicious activity | Yes (cloud) |
AADSTS50126 | AADSTS50126: Error validating credentials due to invalid username or password. | No, but each new wrong password counts toward the lockout |
AADSTS50057 | AADSTS50057: The user account is disabled. | No: the account is disabled, often synced from a disabled AD account |
AADSTS50144 | AADSTS50144 InvalidPasswordExpiredOnPremPassword: the user's AD password has expired | No: reset the password |
Why it happens#
Smart lockout is always on. By default it locks an account after 10 failed attempts (3 in Azure US Government), for one minute at first and longer after repeated lockouts. It keeps separate counters for familiar and unfamiliar locations, so an attacker abroad shouldn't lock out the user at their desk. It also remembers the last three bad password hashes, so the same wrong password repeated doesn't add to the count. Separately, Microsoft blocks sign-ins from IP addresses showing malicious activity and returns the same 50053 code, whatever the password.
Hybrid sign-in changes the picture:
- Password hash sync: Entra ID checks the password itself, so cloud attacks never reach your domain controllers.
- Pass-through authentication (PTA): the agent validates each password against Active Directory, so bad passwords also count toward the AD lockout threshold, and a locked AD account can't sign in to the cloud. Bad-hash tracking isn't available with PTA.
- AD FS: lockout is handled by AD FS Extranet Lockout and Extranet Smart Lockout (AD FS 2016 and 2019), not by Entra ID.
How to fix it#
1. Confirm the reason#
Open Entra ID › Monitoring & health › Sign-in logs, find the failed sign-in with error code 50053 and read the Failure reason: it tells you whether the account was locked or the IP address was blocked.
2. Find the source#
Look at the IP address, location, client app and user agent of the failures before the lockout.
Connect-MgGraph -Scopes "AuditLog.Read.All","Directory.Read.All"
Get-MgAuditLogSignIn -Filter "userPrincipalName eq 'alex@contoso.com' and status/errorCode eq 50126" -Top 50 |
Select-Object CreatedDateTime, IPAddress, ClientAppUsed, AppDisplayName,
@{n='Country';e={$_.Location.CountryOrRegion}}If sign-in logs go to Log Analytics, look across all users:
SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType in ("50053", "50126")
| summarize Failures = count(), Users = dcount(UserPrincipalName) by IPAddress, ClientAppUsed
| order by Failures descMany users failing from a few addresses, often over legacy protocols, points to password spray. One user failing from a known device or office IP points to a stale password saved in a phone, mail app, script or service.
3. Unlock safely#
- A genuine user can wait for the lockout to expire, or use self-service password reset with I forgot my password, which resets the lockout immediately. I know my password doesn't reset the timer.
- An admin can unlock the cloud account without waiting by resetting the user's password.
- If the failures came from an attacker, don't simply unlock: reset the password, make sure the user is covered by MFA and that legacy authentication is blocked, and check Microsoft Entra ID Protection for risk detections such as password spray.
- For a stale credential, update or remove the saved password on the device or app, otherwise the cycle repeats.
4. Hybrid with PTA: align the two lockout policies#
Check the AD policy in Group Policy under Computer Configuration › Policies › Windows Settings › Security Settings › Account Policies › Account Lockout Policy. The Entra threshold must be lower than the AD threshold (Microsoft suggests AD at two to three times the Entra value), and the Entra lockout duration must be longer than the AD duration; note that Entra uses seconds and AD uses minutes. Find on-premises lockouts on the PDC emulator:
$pdc = (Get-ADDomain).PDCEmulator
Get-WinEvent -ComputerName $pdc -FilterHashtable @{LogName='Security'; Id=4740} -MaxEvents 20 |
Select-Object TimeCreated, @{n='User';e={$_.Properties[0].Value}}, @{n='CallerComputer';e={$_.Properties[1].Value}}Each Event ID 4740: A user account was locked out. entry names the caller computer, which is where the bad passwords come from. On the PTA agent servers, the trace logs under %ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\ record a Windows reason code for each failed sign-in; translate it with net helpmsg (1909, for example, is the locked-out account error).
5. Tune smart lockout if needed#
With Microsoft Entra ID P1 or higher, an Authentication Policy Administrator can change Lockout threshold and Lockout duration in seconds (default 60) under Entra ID › Authentication methods › Password protection. The same page holds the custom banned password list and Password Protection for Active Directory, which stop users choosing the guessable passwords sprays rely on.
Verify the fix#
- The user signs in and the sign-in log shows Success, with no new 50053 entries for that account.
- The Log Analytics query above shows the burst has stopped, or the attacking IPs now fail before reaching the password check.
- With PTA, no new 4740 events for the user, and both lockout policies follow the threshold and duration rules above.
Prevent it next time#
- Block legacy authentication and require MFA for everyone; spray attacks lean on protocols that can't do MFA.
- Prefer password hash sync or cloud authentication, which keep cloud attacks away from your domain controllers; see Password hash sync, pass-through authentication or federation.
- Enable self-service password reset so locked-out users recover without the help desk; SSPR and password writeback covers the usual failures.
- Other codes are in the AADSTS error codes quick reference.

