A user can’t log in, and before you know it, the helpdesk phone starts ringing. What might seem like a small issue at first quickly turns into a race against time, especially when the user is blocked from doing their work.
Account lockouts are one of those everyday issues that can quickly snowball. If they’re not handled fast, they lead to missed work, frustrated users, and unnecessary escalations. The tricky part isn’t knowing what to do; it’s getting the right information in front of you quickly enough to act on it. In this post, we walk through three approaches to surfacing locked-out users in your environment.
Why Do Users Get Locked Out?
Not all lockouts are created equal. Before you can resolve one, you need to know which type you’re dealing with. The three most common causes are:
- Failed sign-in attempts – When a user or an attacker submits the wrong password too many times, the account gets locked according to your organization’s account lockout policy. This is the most frequent cause and often happens due to an old password cached on a mobile device, a mapped network drive, or a background service.
- Conditional Access policy blocks – In Entra ID, Conditional Access policies can block sign-ins that don’t meet certain conditions such as requiring a compliant device, a specific location, or multi-factor authentication. Users aren’t technically “locked out” in the traditional sense, but from their perspective the result is identical: they can’t get in.
- Account disablement – Sometimes an account is deliberately disabled, as part of offboarding, a security incident response, or an IT policy violation. Helpdesk staff need to distinguish this from a password lockout so they don’t accidentally re-enable an account that was blocked for a reason.
How to Find Locked-Out Users in Microsoft 365 Environment
In a Microsoft 365 environment, identifying locked-out users depends on whether the account is managed natively in the cloud (Microsoft Entra ID) or in a hybrid environment (On-premises Active Directory).
Using the Entra ID Portal
- The Entra ID portal does have the data you need, but getting to it requires navigating several layers of menus, and it has real limitations around data retention and consolidated views.
- Navigate to Entra ID → Monitoring → Sign-in logs. From there you can filter by status. To isolate failed sign-ins:
- Click Add filters.
- Select Status and choose Failure.
- Optionally add a date range and filter by a specific user’s UPN.
Each log entry shows the error code, which maps to a reason. For example, code 50126 means invalid credentials, while 53003 indicates a Conditional Access block. You can click into an entry to see the full context.
Data retention limits: Sign-in logs are retained for 30 days on P1/P2 licenses, and only 7 days on the free tier. For incidents older than that, you’ll need a Log Analytics workspace or Microsoft Sentinel integration to access historical data.
Via Microsoft 365 Admin Center:
- Log in to the Microsoft 365 admin center.
- Navigate to Users > Active users.
- Click on the Filter set and select Sign-in status: Blocked.
In practice, this means it completely overlooks users who are temporarily locked out due to repeated failed password attempts (smart lockout), as well as users who are effectively blocked by Conditional Access policies but still appear as active accounts. This can create confusion, as users may report being unable to sign in while the admin center shows no issue with their account status.
Using PowerShell (Microsoft Graph):
#Connect to Microsoft Graph
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -Filter "accountEnabled eq false" -ConsistencyLevel eventual `
| Select-Object DisplayName, Mail, UserPrincipalName
#List all users where sign-in is blocked
Get-MgUser -Filter "accountEnabled eq false" | Select-Object DisplayName, Mail, UserPrincipalName However, it has significant limitations when it comes to identifying actual lockout scenarios. The query only returns accounts that are explicitly disabled and does not capture temporary lockouts caused by failed sign-in attempts. Additionally, PowerShell does not provide built-in insight into sign-in failure reasons or Conditional Access decisions, meaning it cannot explain why a user is unable to authenticate.
Find and Fix User Issues Faster with EasyEntra
In day-to-day helpdesk work, speed matters. When users are locked out, you don’t want to spend time navigating multiple portals or building scripts; you just want to find the issue and fix it. EasyEntra is designed with that reality in mind. It provides a single search interface where you can type simple, human-readable queries or LDAP expressions. Instead of switching between tools, everything happens in one place, making the process faster and far less frustrating.
The tool is particularly effective in hybrid environments where Active Directory is synced with Entra ID. In such setups, attributes like lockoutTime and badPwdCount are available and can be queried directly.
In cloud-only environments, however, these attributes may not always be accessible. Because of this limitation, it’s important to validate the feature support with the vendor if your organization does not use on-premises AD.
Finding Locked-Out Users Using EasyEntra
EasyEntra simplifies querying through what it calls relaxed typing. Instead of constructing LDAP queries manually, you can simply type:
lockedout=true Behind the scenes, EasyEntra converts this into the appropriate LDAP query and immediately returns the results. This removes the need for complex syntax while still giving accurate results.
Useful search expressions
A few commonly used queries include:
- lockedout=true → returns all locked-out users
- badpwdcount>0 → shows users with failed login attempts
- disabled=true → identifies disabled accounts
- badpwdtime>2026-01-01 → finds recent failed logins
Find Failed Login Attempts Using EasyEntra
Start by selecting the OU you want to search. Since EasyEntra performs subtree searches by default, all child OUs are included automatically.
Enter badpwdcount>0 in the search field, and the results will update instantly. From there, you can open individual user records, review attributes such as BadPwdCount, or add additional data columns before exporting the results to CSV or TSV, if needed.
The same approach applies when searching for locked-out users. The key advantage is having all relevant data available in one real-time, filterable view.
