AADSTS50057 - User Account Disabled
Azure AADSTS50057 is an account-state error indicating that the user object exists in the target Microsoft Entra tenant but the accountEnabled property is set to false, blocking all authentication attempts.
Last reviewed: April 2, 2026|Editorial standard: source-backed technical guidance
What Does User Account Disabled Mean?
AADSTS50057 signals a "Valid Identity, Invalid State." Entra ID successfully identifies the user but finds the account is locked at the directory level. Crucially, in B2B scenarios, a user can be perfectly active in their "Home Tenant" but hit this error because their "Guest" object in your "Resource Tenant" was disabled. It is the definitive signal that the user has been offboarded or manually restricted in the context of the specific directory being accessed.
Common Causes
- -Administrative Deactivation: A tenant admin manually toggled "Account Enabled" to "No" in the Entra ID portal.
- -HR/Offboarding Automation: A Joiner-Mover-Leaver (JML) process or an automated cleanup script disabled the user after a period of inactivity.
- -Hybrid Sync Conflict: The user was disabled in the on-premises Active Directory, and the
userAccountControlattribute synced the disabled state to the cloud. - -Access Review Governance: An automated Entra ID Access Review resulted in a deny outcome, which automatically disabled the guest account for security compliance.
- -Stale B2B Guest Object: A long-term partner user still has an account, but it was disabled during a security audit while their home account remains active.
How to Fix User Account Disabled
- 1Verify Target Tenant: Ensure you are checking the Account Enabled status in the specific tenant where the app lives (the Resource Tenant).
- 2Toggle accountEnabled: If the disablement was accidental, go to Entra ID > Users, find the user, and set Account Enabled to Yes.
- 3Force On-Prem Sync: If hybrid-synced, re-enable the account in On-Prem AD and trigger a Delta Sync via PowerShell:
Start-ADSyncSyncCycle -PolicyType Delta. - 4Audit Guest State: For B2B users, ensure the User Type is Guest and that the account has not been flagged by Identity Protection for risk-based deactivation.
Step-by-Step Diagnosis for User Account Disabled
- 1Inspect the Sign-in Logs in the Entra admin center and look for "Result detail: User account is disabled."
- 2Run
az ad user show --id <UPN>and look specifically for the"accountEnabled": falseJSON property. - 3Check the source of the user. If it is Windows Server AD, the fix must happen on-premises.
- 4Review the audit logs for the user object to see the specific service principal or admin who triggered the deactivation.
State Comparison Matrix
- -AADSTS50057 (Disabled): Identity exists; gate is locked.
- -AADSTS50034 (Not Found): Identity does not exist; no gate found.
- -AADSTS50055 (Expired): Identity exists; gate is open but your key is too old.
The B2B Double-State Trap
- -A user has two states in B2B: active in Company A, but potentially disabled in Company B. AADSTS50057 always refers to the state in the organization hosting the application.
Implementation Examples
az ad user show --id user@example.com --query "accountEnabled"
# If output is 'false', you have confirmed AADSTS50057.try {
const loginResponse = await msalInstance.loginPopup(loginRequest);
} catch (error) {
if (error.errorMessage.includes("AADSTS50057")) {
console.error("Critical: User account is administratively disabled.");
// Trigger "Contact IT Support" UI flow
}
}How to Verify the Fix
- -Confirm the
accountEnabledproperty returnstruevia Graph API or Azure Portal. - -Ask the user to sign in using an incognito window to bypass any disabled state cached in the browser session.
- -Verify that the Sign-in Log entry for the user transitions from failure to success.
How to Prevent Recurrence
- -Governance Safeguards: Exclude break-glass or critical service accounts from automated cleanup and Access Review scripts.
- -Monitoring Alarms: Set up an Azure Monitor alert for a spike in 50057 errors, which could indicate a bug in your offboarding automation.
- -Owner Assignment: Ensure every B2B guest account has a designated internal sponsor to prevent accidental deactivation during bulk cleanups.
- -Pro-tip: When disabling accounts for offboarding, add a note in the Description field of the user object stating why and who requested it. This removes guesswork when 50057 appears later.
Decision Support
Compare Guide
429 Too Many Requests vs 503 Service Unavailable
Use 429 for caller-specific throttling and 503 for service-wide outages, so retry behavior, escalation paths, and incident ownership stay correct.
Compare Guide
500 Internal Server Error vs 502 Bad Gateway: Root Cause
Debug 500 vs 502 faster: use 500 for origin failures and 502 for invalid upstream responses at gateways, then route incidents to the right team.
Playbook
API Timeout Playbook (502 / 504 / DEADLINE_EXCEEDED)
Use this playbook to separate invalid upstream responses from upstream wait expiration and deadline exhaustion, and apply timeout budgets, safe retries, and circuit-breaker controls safely.
Playbook
Availability and Dependency Playbook (500 / 503 / ServiceUnavailable)
Use this playbook to separate origin-side 500 failures from temporary 503 dependency or capacity outages, then apply safe retry and escalation paths.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.