Interactive Troubleshooter

Published: Oct 18, 2026

Account Locked After Too Many Attempts in Microsoft 365 - Admin Unlock Tree

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Exhaustive administrative diagnostic tree to resolve Microsoft 365 user account lockouts triggered by Microsoft Entra ID Smart Lockout, bad password flooding, active Directory synchronization loops, or persistent legacy protocol authentication caching.

Full Diagnostic Tree & Step-by-Step Overview

What is the primary origin or environment behavior associated with the M365 account lockout?

Single user Cloud-Only account experiencing repeated lockouts shortly after manual unlock
Hybrid environment where lockouts originate on-premises or loop via Microsoft Entra Connect Sync
Account repeatedly locks due to automated background apps, mobile devices, or stale cached credentials
Mass or tenant-wide account lockouts caused by password spray or brute-force attacks across IP ranges

What sign-in error or behavior is displayed in the Entra ID Sign-in logs for this cloud-only user?

Error 50053: Account locked out due to too many invalid sign-in attempts (Smart Lockout triggered)
Error 50057: User account is explicitly disabled or sign-in is blocked by an Administrator
Error 50126: Invalid username/password accompanied by rapid MFA prompt failures
User is locked out despite entering the correct password immediately after a password reset

Fixing Entra ID Smart Lockout (Error Code 50053) for Cloud-Only Accounts

Solution:

Root Cause: Entra ID Smart Lockout Protection Triggered

Microsoft Entra ID (formerly Azure Active Directory) enforces Smart Lockout to protect accounts against password attacks. Unlike traditional Active Directory lockouts, Smart Lockout tracks bad password attempts using two metrics: invalid password count and request IP location tracking. When a threshold (default: 10 bad attempts) is reached from an unfamiliar IP, Entra ID locks out attempts from that specific location while allowing legitimate attempts from familiar locations. If attempts continue from multiple locations, the account is completely locked out globally to prevent account takeover.

Diagnostic Verification:

Access the Microsoft Entra Admin Center and navigate to Identity > Users > Sign-in logs.

Filter by the affected user UPN and check for Error Code 50053 (*'IdsError: 50053 - Account is locked because the user tried to sign in too many times with an incorrect user ID or password.'*).

Verify the source IP, Client App, and User Agent in the log entry to determine if bad attempts originate from external malicious IPs or internal user devices.

Step-by-Step Fix:

1.Revoke User Sessions and Reset Sign-In Status:

Open Microsoft Entra Admin Center, locate the user under Users > All users, and select Revoke sessions to invalidate active refresh tokens.

Click Block sign-in, toggle the option to Yes, save, and then toggle back to No and save to reset the cloud sign-in block state.

2.Clear Smart Lockout Counter via PowerShell:

Connect to Microsoft Graph PowerShell using administrative scope:

powershell
   Connect-MgGraph -Scopes "User.ReadWrite.All", "Directory.ReadWrite.All"

Force clear the authentication credentials metadata and update user state:

powershell
   Update-MgUser -UserId "user@yourdomain.com" -AccountEnabled:$true
   Revoke-MgUserSignInSession -UserId "user@yourdomain.com"

3.Tune Smart Lockout Thresholds in Security Policy:

Navigate to Protection > Authentication methods > Password protection in the Entra Admin Center.

Review the Smart lockout threshold (default 10) and Lockout duration in seconds (default 60 seconds).

Adjust the threshold higher if aggressive background services trigger lockouts during password updates.

4.Force Password Reset with MFA Requirement:

Initiate a forced password reset from the Entra portal and ensure SSPR or Admin reset generates a strong temporary credential.

Prevention & Long-Term Monitoring:

Require MFA for all sign-in attempts by enforcing Conditional Access policies across the tenant.

Configure Entra ID Diagnostic Settings to stream SignInLogs to an Azure Log Analytics workspace and create alert rules for repeated Error Code 50053 events.

Resolving Explicit Administrative Sign-In Blocks (Error Code 50057)

Solution:

Root Cause: Account State Set to Disabled or Blocked

When a sign-in attempt returns Error Code 50057, the user object has its accountEnabled attribute explicitly set to $false. This is typically triggered by automated risk remediation scripts (e.g., Entra ID Identity Protection high-risk user automated response), administrative HR offboarding workflows, or manual admin action following a compromised credential alert.

Diagnostic Verification:

Query Entra Audit logs filtered by target user UPN to identify the actor that modified AccountEnabled state:

powershell
Get-MgAuditLogDirectoryAudit -Filter "targetResources/any(tr:tr/id eq 'USER_OBJECT_ID')" | Select-Object ActivityDateTime, ActivityDisplayName, InitiatedBy

Check if Entra ID Identity Protection flagged the account as High Risk.

Step-by-Step Fix:

1.Unblock Sign-in via Entra Admin Center:

Go to Identity > Users > All users, select the target user account.

Under Properties, click Edit settings, set Block sign-in to No, and click Save.

2.Remediate High Risk State in Identity Protection:

Navigate to Protection > Identity Protection > Risky users.

Select the user and click Dismiss user risk or Confirm user compromised followed by a password reset.

3.Unblock via Microsoft Graph PowerShell:

powershell
   Connect-MgGraph -Scopes "User.ReadWrite.All"
   Update-MgUser -UserId "user@yourdomain.com" -AccountEnabled:$true

Prevention & Long-Term Monitoring:

Review Identity Protection automated risk policies under Protection > Conditional Access > User risk policy to avoid unintended account disables during normal travel or IP changes.

Fixing Invalid Credential and MFA Lockout Loops (Error Code 50126)

Solution:

Root Cause: Primary Credential Validation Failure with MFA Exhaustion

Error Code 50126 indicates that the user entered an incorrect password, triggering an authentication failure that exhausts MFA evaluation limits. When a user or automated agent repeatedly supplies a valid UPN with an outdated password, modern authentication flows block additional attempts at the pre-MFA layer to prevent MFA fatigue and notification spamming.

Diagnostic Verification:

Inspect Entra ID Sign-in logs for ResultType 50126.

Verify if sign-ins fail at Primary Authentication or during secondary MFA processing.

Step-by-Step Fix:

1.Clear Stale Browser and App Authenticator Tokens:

Have the user sign out of all Microsoft applications, clear web browser cache and cookies, and delete saved browser auto-fill credentials.

2.Re-register MFA Authentication Methods:

In Entra Admin Center, navigate to Users > All users > [User] > Authentication methods.

Click Require re-register MFA and Revoke MFA sessions.

3.Issue Temporary Access Pass (TAP):

Generate a Temporary Access Pass under Authentication methods > Add authentication method > Temporary Access Pass.

Have the user log into https://myaccount.microsoft.com using the TAP to establish a fresh credential baseline and update their password.

Prevention & Long-Term Monitoring:

Transition users to passwordless authentication methods (FIDO2 security keys or Microsoft Authenticator number matching) to eliminate password-related lockout loops.

Resolving Post-Password Reset Persistent Lockout

Solution:

Root Cause: Credential Propagation Delay and Token Cache Collision

When an administrator resets a user password in M365, primary authentication endpoints update immediately. However, active Primary Refresh Tokens (PRTs) stored on local Entra joined / Hybrid joined devices continue presenting stale claims to token endpoints until refreshed. Background sync workers (like Exchange ActiveSync or OneDrive sync clients) continue using cached credentials, immediately re-triggering the bad password counter against the new baseline.

Diagnostic Verification:

Run dsregcmd /status on the user's primary Windows endpoint and note the AzureAdPrt status and time stamp.

Review Sign-in logs to confirm bad password attempts originate from client applications (e.g., Office 365 Exchange Online, OneDrive) using legacy or basic authentication protocols.

Step-by-Step Fix:

1.Disconnect Network Access on User Devices:

Temporarily place the user's workstation/mobile device in flight mode or disconnect Ethernet to stop background credential flooding.

2.Purge Local Windows Credential Manager:

Open Credential Manager on Windows, select Windows Credentials, and delete all entries under MicrosoftOffice16_Data, adal_generic, and WindowsLive.

3.Disconnect and Re-acquire PRT:

Open an elevated Command Prompt on the user machine and execute:

cmd
   dsregcmd /debug /leave

Alternatively, force PRT renewal without leaving domain:

cmd
   klist purge

4.Revoke M365 Sessions via PowerShell:

powershell assessment
   Revoke-MgUserSignInSession -UserId "user@yourdomain.com"

5.Reconnect Device and Perform Clean Sign-in:

Re-enable network connectivity and sign in directly to Microsoft 365 Web applications (https://portal.office.com) before launching desktop apps.

Prevention & Long-Term Monitoring:

Educate users to update saved credentials on mobile devices (iOS Mail / Android Outlook) immediately prior to performing desktop password updates.

What is the specific synchronization or active directory symptom occurring in the hybrid setup?

On-premises Active Directory locks the account, which then syncs and locks M365 via Entra Connect
M365 cloud lockouts occur despite the on-premises Active Directory account remaining unlocked
Password Hash Synchronization (PHS) or Pass-Through Authentication (PTA) is failing validation
Active Directory Federated Services (ADFS) Extranet Lockout policy is blocking cloud sign-ins

Fixing On-Premises Active Directory to M365 Synchronized Lockout

Solution:

Root Cause: Hybrid Account Lockout Propagation via Entra Connect

In hybrid environments using Password Hash Synchronization (PHS) with Enforce Cloud Password Policy for Password Hashes enabled, or Pass-Through Authentication (PTA), account lockout states are governed by on-premises Active Directory Domain Controllers. Bad password attempts made in the cloud are sent to on-premises AD via PTA agents or evaluated locally. When on-premises AD threshold (LockoutThreshold) is exceeded, the account sets the badPwdCount and lockoutTime attributes, disabling authentication across both environments.

Diagnostic Verification:

Open PowerShell on a Domain Controller and inspect bad password count and lockout status:

powershell
Get-ADUser -Identity "username" -Properties AccountLockoutTime, BadLogonCount, LastBadPasswordAttempt, LockedOut | Format-List

Review Event Viewer Log Security on Domain Controllers for Event ID 4740 (*A user account was locked out*) to locate the originating caller computer name.

Step-by-Step Fix:

1.Identify and Terminate Lockout Source Process:

Search for Event ID 4740 in the DC Security log to identify Caller Computer Name.

Log onto the caller machine and use LockoutStatus.exe or PowerShell to identify services, scheduled tasks, persistent drives, or stale browser sessions running under the target user credentials.

2.Unlock Account in Active Directory:

powershell
   Unlock-ADAccount -Identity "username"

3.Force Delta Synchronization via Entra Connect Sync:

Log onto the Microsoft Entra Connect server and run:

powershell
   Start-ADSyncSyncCycle -PolicyType Delta

4.Verify Cloud State Resolution:

Check Entra Admin Center to confirm the lockout flag clears after the sync cycle completes.

Prevention & Long-Term Monitoring:

Enable Microsoft Entra Password Protection for Active Directory Domain Controllers to synchronize banned password lists and smart lockout logic between cloud and on-premises environments.

Resolving M365 Cloud Lockout with Unlocked On-Premises AD Account

Solution:

Root Cause: Asymmetric Cloud Smart Lockout in Hybrid Setup

When using Password Hash Sync (PHS) without seamless SSO, Microsoft Entra ID maintains an independent Smart Lockout state in the cloud to prevent malicious entities from exhausting on-premises Active Directory lockout thresholds. If an external attacker attempts to brute-force a user via M365 endpoints, Entra ID Smart Lockout will block cloud sign-ins while leaving the on-premises Active Directory account completely unlocked.

Diagnostic Verification:

Verify on-premises status: Get-ADUser -Identity "username" -Properties LockedOut returns False.

Inspect Entra ID Sign-in logs: Status shows Failure, Error Code 50053, and IP addresses belong to untrusted external locations.

Step-by-Step Fix:

1.Clear Cloud Smart Lockout State:

Connect to Microsoft Graph PowerShell and reset user account state:

powershell
   Update-MgUser -UserId "user@yourdomain.com" -AccountEnabled:$true
   Revoke-MgUserSignInSession -UserId "user@yourdomain.com"

2.Verify Pass-Through Authentication (PTA) Agent Health (If applicable):

Open Entra Admin Center, navigate to Identity > Hybrid management > Microsoft Entra Connect > Pass-through authentication.

Ensure all PTA agents show status Active.

3.Implement IP Named Locations to Protect Account:

Go to Protection > Conditional Access > Named locations.

Mark enterprise public egress IPs as Trusted.

Configure Entra Smart Lockout policy to differentiate between corporate egress IPs and external IPs.

Prevention & Long-Term Monitoring:

Deploy Conditional Access policies to block sign-in attempts from countries/regions where your organization has no business presence.

Fixing Pass-Through Authentication (PTA) / PHS Lockout Validation Errors

Solution:

Root Cause: PTA Agent Timeout or Unreachable Domain Controllers

When authenticating via Pass-Through Authentication (PTA), Entra ID streams sign-in requests down to locally installed PTA agents on-premises, which validate credentials against Active Directory using Win32 logoff/logon APIs. If PTA agents are overloaded, unable to reach Domain Controllers via RPC/Kerberos, or if outbound HTTPS communication over Port 443 to Microsoft endpoints is throttled, requests time out. Entra ID interprets repeated agent timeouts or failed API returns as bad password attempts, triggering an account lockout.

Diagnostic Verification:

On the PTA agent server, inspect Event Viewer under Applications and Services Logs > Microsoft > AzureADConnect > AuthenticationAgent > Admin.

Look for Event ID 20004 (*'Error occurred while processing authentication request'*) or Event ID 20016 (*'No Domain Controller could be contacted'*).

Step-by-Step Fix:

1.Check PTA Agent Connectivity and Service Status:

Open services.msc on the agent host and verify Microsoft Entra Connect Authentication Agent is running.

2.Test Outbound Port 443 Endpoint Reachability:

powershell
   Test-NetConnection -ComputerName "servicebus.windows.net" -Port 443

3.Restart PTA Services and Re-register Agent:

Restart the authentication service on all agent servers.

If errors persist, uninstall the agent and reinstall the latest version from the Entra Admin Center portal.

4.Enable Staging / Fallback Agent:

Install at least three PTA agents across distinct physical servers to ensure high availability and prevent validation queues.

Prevention & Long-Term Monitoring:

Monitor PTA agent server CPU, memory, and domain controller network latency to ensure authentication requests process in under 2000ms.

Resolving ADFS Extranet Smart Lockout (ESL) Account Blocks

Solution:

Root Cause: ADFS Extranet Lockout Policy Mitigation

For organizations using Active Directory Federation Services (ADFS) for identity federation, account lockouts occurring at the federation boundary are governed by ADFS Extranet Smart Lockout (ESL). ESL protects on-premises AD accounts from extranet brute-force attempts by enforcing bad password limits at the Web Application Proxy (WAP) layer. If ESL triggers, ADFS rejects authentication tokens to Microsoft 365, presenting users with a lockout error page.

Diagnostic Verification:

On the primary ADFS server, open PowerShell and query the user's Extranet Lockout state:

powershell
Get-AdfsAccountActivity -UserPrincipalName "user@yourdomain.com"

Review output fields BadPwdCountFamiliar, BadPwdCountUnknown, and AccountState (e.g., LOCKEDOUT).

Step-by-Step Fix:

1.Reset ADFS Account Activity State for User:

Execute the following command on the primary ADFS server to clear the extranet lockout counters immediately:

powershell
   Reset-AdfsAccountActivity -UserPrincipalName "user@yourdomain.com"

2.Verify ADFS ESL Policy Parameters:

Check current lockout configuration thresholds:

powershell
   Get-AdfsProperties | Select-Object EnableExtranetLockout, ExtranetLockoutThreshold, ExtranetObservationWindow

3.Update Malicious IP Banning in ADFS:

Verify that ADFS is in Log-only or Enforce mode for Smart Lockout, and add offending external IPs to the ADFS Blocked IP List.

Prevention & Long-Term Monitoring:

Plan migration from ADFS federation to Managed Authentication (Pass-Through Authentication or Password Hash Sync with Seamless SSO) to simplify security architecture and leverage cloud-native protection features. For step-by-step guidance, refer to the Microsoft Official Support Guide on hybrid authentication choices.

Which background service or client application is generating the persistent bad attempts?

Legacy Authentication protocols (POP3, IMAP4, SMTP AUTH, Exchange ActiveSync)
Stale Windows Credential Manager entries, cached Office tokens, or Mapped Network Drives
Mobile devices (iOS Mail, Android Outlook) maintaining stale sync profiles after password change
Third-party SaaS app integrations, PowerShell scripts, or automated API service accounts

Remediating Legacy Authentication Lockout Loops

Solution:

Root Cause: Legacy Authentication Protocol Credential Flooding

Legacy authentication protocols (e.g., POP3, IMAP4, Authenticated SMTP, Exchange ActiveSync) do not support modern authentication interactive prompts or MFA. When a user updates their M365 password, legacy mail clients or automated mail scripts continue transmitting the old password in plain text/basic auth headers. Because these requests bypass modern MFA protections, they directly hit basic authentication endpoints, continuously incrementing the user's bad password count until Smart Lockout engages.

Diagnostic Verification:

Go to Entra Admin Center > Identity > Users > Sign-in logs.

Add a filter for Client App: Select AutoDiscover, Exchange ActiveSync, IMAP, POP, and Other clients.

Look for failed sign-ins with Error Code 50053 or 50126 associated with legacy protocols.

Step-by-Step Fix:

1.Disable Legacy Authentication at Tenant Level:

Open Entra Admin Center, navigate to Protection > Conditional Access.

Create a policy named Block Legacy Authentication.

Under Assignments > Users, select All users (exclude emergency break-glass accounts).

Under Target resources, select All cloud apps.

Under Conditions > Client apps, toggle to Yes and check Exchange ActiveSync clients and Other clients.

Under Access controls > Grant, select Block access and enable the policy.

2.Turn off Transport-Level Legacy Protocols in Exchange Online:

Connect to Exchange Online PowerShell:

powershell
   Connect-ExchangeOnline

Disable POP, IMAP, and SMTP AUTH for the specific affected user:

powershell
   Set-CASMailbox -Identity "user@yourdomain.com" -PopEnabled $false -ImapEnabled $false -SmtpClientAuthenticationDisabled $true

3.Unlock the Account:

Revoke active sessions via Entra ID or PowerShell to clear the lockout flag.

Prevention & Long-Term Monitoring:

Audit tenant-wide legacy authentication usage using Exchange Online Authentication Policies to enforce complete deprecation across all mailboxes.

Purging Windows Credential Manager and Local Office Caches

Solution:

Root Cause: Cached Windows Credential Manager and Identity Token Corruption

Windows stores domain and web credentials in the local Credential Manager database. Microsoft 365 desktop apps (Outlook, Teams, OneDrive) read tokens stored in Web Account Manager (WAM) and Credential Manager. When a password is changed, background sync agents (e.g., onedrive.exe, outlook.exe, or mapped SharePoint WebDAV drives) continuously re-try stored credentials before modern authentication prompts appear on-screen, causing immediate lockouts upon rebooting or unlocking Windows.

Diagnostic Verification:

Check local Windows Event Viewer under Applications and Services Logs > Microsoft > Windows > AAD > Operational.

Look for Error 0xCAA20003 or 0xCAA82EE2 indicating token acquisition failures.

Step-by-Step Fix:

1.Close All Office Applications:

Terminate outlook.exe, teams.exe, onedrive.exe, and msaccess.exe via Task Manager.

2.Purge Stale Credentials from Credential Manager:

Open Start, search for Credential Manager, and select Windows Credentials.

Remove all entries matching:

MicrosoftOffice16_Data:*

adal_generic

WindowsLive:*

identity_platform_token

3.Clear Office Identity Registry Keys:

Open regedit.exe and navigate to:

HKCU\Software\Microsoft\Office\16.0\Common\Identity

Delete the Identities subkey folder to reset application identity bindings.

4.Reset WAM Account State:

Open PowerShell as user and clear the identity broker cache:

powershell
   Get-AppxPackage *AADPage* | Reset-AppxPackage

5.Re-launch App and Sign In:

Open Outlook and complete the interactive modern authentication prompt.

Prevention & Long-Term Monitoring:

Deploy Enterprise Endpoint policies to enforce Web Account Manager (WAM) default behavior and prevent desktop apps from caching plain-text password tokens.

Resolving Mobile Device (iOS/Android) Background Sync Lockout

Solution:

Root Cause: Mobile Email ActiveSync and OAuth Token Refresh Failures

Native mobile email clients (such as native iOS Mail or older Android email apps) configured with Basic Auth or stale OAuth refresh tokens continue polling Exchange Online in the background. When a user updates their password, the mobile OS background task repeatedly sends outdated credentials every few minutes. This continuous background polling silently triggers Entra Smart Lockout without presenting a visible prompt to the user.

Diagnostic Verification:

Check Entra ID Sign-in logs and filter by UserAgent: Look for Apple-iPhone, Apple-iPad, or Outlook-iOS-Android entries returning Error Code 50053.

Cross-reference the timestamp of lockouts with background mobile sync activity.

Step-by-Step Fix:

1.Locate and Isolate Offending Mobile Device:

Check Exchange Online ActiveSync device associations for the user:

powershell
   Get-MobileDeviceStatistics -Mailbox "user@yourdomain.com" | Select-Object DeviceModel, DeviceOS, LastSuccessSync

2.Remove or Update Account Profile on Device:

On the mobile device, navigate to Settings > Accounts / Mail.

Remove the M365 account entirely, or select Edit Password and supply the newly updated credential.

3.Force Mobile Session Revocation via Intune / Entra:

In Entra Admin Center, locate the user, click Revoke sessions.

If managed via Microsoft Intune, issue a Wipe or Retire action on obsolete corporate devices.

4.Re-install Modern Outlook Mobile App:

Recommend installing the official Microsoft Outlook app from the App Store / Google Play Store, which uses modern broker-assisted authentication (Microsoft Authenticator) and avoids ActiveSync lockout bugs.

Prevention & Long-Term Monitoring:

Implement Intune App Protection Policies (MAM) and Conditional Access to mandate the official Outlook app and block native device mail clients.

Fixing Automated Script, Service Account, and API Integration Lockouts

Solution:

Root Cause: Hardcoded Credentials in Automated Workflows and Scripts

Service accounts or licensed user accounts utilized for automated tasks (e.g., PowerShell maintenance scripts, scheduled tasks, LOB application integrations, or backup tools) store credentials in cleartext scripts, configuration files, or environment variables. When an administrator enforces a periodic password reset on the account, automated tasks execute on schedule, presenting old credentials and triggering a lockout.

Diagnostic Verification:

Review Entra Sign-in logs for Client App listed as PowerShell, Python, Custom App, or REST API.

Filter Audit logs for Application ID associated with service principal calls vs interactive sign-ins.

Step-by-Step Fix:

1.Identify Script and Scheduled Task Executions:

Search internal server infrastructure for scheduled tasks running under the affected account name:

powershell
   Get-ScheduledTask | Where-Object {$_.Principal.UserId -like "*username*"}

2.Convert Automated Workflows to Non-Interactive Certificate Authentication:

Replace hardcoded user passwords in scripts with Entra Application Registrations using Service Principals and Certificate Credentials (or Managed Identities in Azure).

3.Exempt Dedicated Service Accounts from Interactive Password Expiration Policies:

Set password never to expire for dedicated service accounts, or configure Managed Identities:

powershell
   Set-MgUser -UserId "serviceaccount@yourdomain.com" -PasswordPolicies "DisablePasswordExpiration"

4.Unlock Account and Test Script Execution:

Reset user state and run non-interactive authentication test using certificate parameters:

powershell
   Connect-MgGraph -ClientId "YOUR_APP_ID" -TenantId "YOUR_TENANT_ID" -CertificateThumbprint "THUMBPRINT"

Prevention & Long-Term Monitoring:

Mandate Azure Managed Identities for all Azure-hosted workloads and eliminate interactive user accounts for automated API tasks.

What type of attack or wide-scale pattern is triggering the tenant lockouts?

Distributed Password Spray attack targeting multiple accounts from anonymized proxy/VPN IPs
Brute-force attack concentrated against specific public-facing Exchange endpoints or Autodiscover
Compromised internal host or compromised VPN user spraying credentials inside the corporate network
MFA Fatigue (Push Spam) leading to account locking after repeated user MFA rejections

Mitigating Distributed Password Spray Attacks in M365

Solution:

Root Cause: External Distributed Password Spray Attack

In a password spray attack, an adversary attempts a small number of commonly used passwords (e.g., SeasonYear!, Password123) across thousands of accounts in a tenant. By staying below the per-IP threshold, attackers attempt to evade simple lockout rules. However, because Entra Smart Lockout monitors global failure volume across all IPs, the aggregate bad attempts trigger tenant-wide Smart Lockout blocks, locking legitimate users out of their accounts.

Diagnostic Verification:

Export Sign-in logs using Microsoft Graph PowerShell or Log Analytics and analyze sign-in failure trends:

powershell
Get-MgAuditLogSignIn -Filter "status/errorCode eq 50053" -Top 500 | Group-Object IPAddress | Sort-Object Count -Descending

Verify if bad attempts originate from TOR exit nodes, residential proxies, or cloud hosting ranges (e.g., AWS, DigitalOcean).

Step-by-Step Fix:

1.Enable Entra ID Smart Lockout Protection Thresholds:

Go to Entra Admin Center > Protection > Password protection.

Lower Smart lockout threshold to 5 and set Lockout duration to 300 seconds to throttle attacker speed.

2.Deploy Location-Based Conditional Access Rules:

Go to Conditional Access > Policies > New Policy.

Under Conditions > Locations, configure Include: Any location, Exclude: Selected locations (Your Trusted Egress IPs).

Under Access controls, select Block access.

3.Enable Certificate-Based Authentication or Mandatory FIDO2:

Require strong phishing-resistant MFA to invalidate sprayed passwords even if correctly guessed.

4.Enforce Custom Banned Password Lists:

Under Password protection, enable Enforce custom list and add company names, local sports teams, and seasonal variations.

Prevention & Long-Term Monitoring:

Integrate Entra ID with Microsoft Sentinel and enable the automated playbook NRT-Password-Spray-Remediation to block offending IP ranges automatically at your perimeter firewall.

Blocking Brute-Force Attacks on Public Exchange / Autodiscover Endpoints

Solution:

Root Cause: Targeted Brute-Force Against Basic Authentication Endpoints

Attacking actors target legacy protocol endpoints such as https://outlook.office365.com/EWS/Exchange.asmx or Autodiscover using automated script tools (e.g., Hydra, Ruler). Because basic authentication endpoints do not natively render MFA prompts, attackers attempt rapid dictionary attacks against these endpoints. The resulting volume of bad password submissions causes Entra ID to flag accounts as compromised and lock sign-in capabilities across all M365 portals.

Diagnostic Verification:

Review Entra Sign-in logs filtering for Client App: Exchange Web Services or Autodiscover.

Confirm high failure rate associated with ResultType: 50126 and 50053.

Step-by-Step Fix:

1.Disable Exchange Web Services (EWS) Basic Auth:

Connect to Exchange Online PowerShell:

powershell
   Connect-ExchangeOnline

Create an authentication policy blocking basic auth:

powershell
   New-AuthenticationPolicy -Name "BlockBasicAuthGlobal" -AllowBasicAuthActiveSync:$false -AllowBasicAuthAutodiscover:$false -AllowBasicAuthEws:$false -AllowBasicAuthPowershell:$false
   Set-OrganizationConfig -DefaultAuthenticationPolicy "BlockBasicAuthGlobal"

2.Apply Policy to Mailboxes:

powershell
   Get-User -ResultSize Unlimited | Set-User -AuthenticationPolicy "BlockBasicAuthGlobal"

3.Unblock Affected Accounts:

Clear the lockout status using Entra PowerShell (Revoke-MgUserSignInSession).

Prevention & Long-Term Monitoring:

Periodically run Microsoft Graph reports to verify that zero mailboxes have active basic authentication endpoints enabled.

Remediating Internal Network Credential Spraying from Compromised Hosts

Solution:

Root Cause: Lateral Movement and Internal Credential Spraying

If a workstation or server inside the internal corporate network is compromised by malware (e.g., Cobalt Strike, Mimikatz), the malware may harvest domain user lists and attempt internal NTLM/Kerberos or M365 API credential spraying across internal subnets. Because requests originate from trusted corporate egress IP addresses, Entra ID Smart Lockout treats these attempts as coming from a familiar location, causing rapid local and cloud lockouts for internal employees.

Diagnostic Verification:

Inspect internal Active Directory Domain Controller Security logs for Event ID 4776 (*The domain controller attempted to validate the credentials for an account*) or Event ID 4625 (*An account failed to log on*).

Identify the source internal IP or workstation name submitting bad NTLM requests.

Step-by-Step Fix:

1.Isolate Source Workstation from Network:

Instantly disconnect the offending workstation from Ethernet/Wi-Fi or issue a Contain Device command via Microsoft Defender for Endpoint.

2.Perform Antivirus / EDR Remediation Scan:

Run an elevated Full Antivirus scan and investigation package via Defender for Endpoint to isolate memory-resident malware processes.

3.Unlock Affected Internal Users:

powershell
   Unlock-ADAccount -Identity "affecteduser"

4.Reset Privileged Credentials:

Change passwords for all domain admin and local admin accounts that signed into the compromised host.

Prevention & Long-Term Monitoring:

Deploy Defender for Identity (MDI) sensors on all Domain Controllers to detect internal credential spraying and lateral movement maneuvers in real-time.

Resolving MFA Fatigue (Push Spam) and Fraud-Induced Lockouts

Solution:

Root Cause: Account Lockout Triggered by MFA Fraud Reporting and Push Rejections

When an attacker obtains a user's correct password, they trigger continuous MFA push notifications to the user's mobile device (MFA Fatigue). If the user repeatedly selects Deny or taps the Report Fraud button in the Microsoft Authenticator app, Entra ID automatically flags the account as high risk, applies an emergency sign-in block, and locks out all further authentication attempts to prevent unauthorized entry.

Diagnostic Verification:

Check Entra Audit logs for Activity: Report fraud or User reported suspicious activity.

Inspect Sign-in logs for Error Code 500121 (*'Authentication failed during MFA request'*).

Step-by-Step Fix:

1.Reset Password Immediately:

Since the attacker possesses the valid primary password, perform an immediate forced password reset in Entra Admin Center.

2.Clear Fraud Block Status in Entra ID:

Navigate to Entra Admin Center > Protection > Multifactor authentication > Block/unblock users.

Locate the user, select Unblock, and enter a reason for unblocking.

3.Enable Authenticator Number Matching and Location Context:

Go to Protection > Authentication methods > Microsoft Authenticator.

Under Configure, set Require number matching for push notifications to Enabled for All users.

Set Show application name in push notifications and Show geographic location to Enabled.

4.Revoke Active Sessions:

powershell
   Revoke-MgUserSignInSession -UserId "user@yourdomain.com"

Prevention & Long-Term Monitoring:

Require number matching across all tenant authentication policies to render automated MFA fatigue attacks completely ineffective.

Related Diagnostic Guides

Ubuntu Black Screen After Nvidia Driver Install - Secure Boot Diagnostic

SSH Connection Refused on Port 22 But Service Running - Firewall Tree

Linux Boot Stuck at GRUB Rescue After Windows Update - Dual Boot Fix

SmartScreen Can't Be Reached Right Now Error Fix - Windows Diagnostic Guide

Windows 11 Wi-Fi Connected but No Internet? How to Fix It

Subscribe to StepDiag

Embed Guide on Your Website