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|Source-backed guidance under our editorial policy
Start Here
Use the closest compare guide, playbook, or adjacent error page to narrow the decision faster before you start changing production systems.
This page is part of the Error Reference library. Learn more about the project or report a correction.
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
}
}Seen in Production
The Contractor Return Failure
Frequency: high
Example: A contractor returns after 6 months. Their account still exists in the tenant but was disabled by an inactivity script. They try to log in and hit 50057.
Fix: Locate the existing account and toggle it back to enabled instead of creating a duplicate user.
Debugging Tools
- -Entra ID Users Blade: The primary UI for re-enabling accounts.
- -Microsoft Graph Explorer: Use
GET https://graph.microsoft.com/v1.0/users/{id}to check the accountEnabled property. - -Azure AD Connect Health: To verify if a disabled state is being forced from on-premises.
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.
Official References
Provider Context
This guidance is specific to Azure services. Always validate implementation details against official provider documentation before deploying to production.