AADSTS50057: User account is disabled

What does AADSTS50057 mean?

UserDisabled: The user account is disabled. The user object in Active Directory backing this account has been disabled. An admin can re-enable this account through PowerShell

The account exists but is switched off (accountEnabled = false), so Entra refuses the sign-in. Microsoft’s wording mentions the Active Directory object, but the code is the same for a cloud-only account disabled in Entra ID. In hybrid tenants the disable is often done on-premises and synced up, so check both places when re-enabling.

Is it an attack?

Microsoft’s password spray playbook lists “50057 - User account was disabled” among the sign-in events to review in a spray investigation. Most 50057 rows are still harmless. Read the pattern:

Pattern	Likely meaning
One recently offboarded user, from their old device or usual IP	A phone, mail client or synced app still trying with the old account. Benign, but clean it up.
Rows in the non-interactive log for a leaver	An app still holding a token for that user and retrying silently. Revoke sessions.
Many different disabled accounts from one IP	In practice, a spray working from an old or leaked user list. Disabled leavers and shared mailboxes are on those lists. (T1110.003)
50057 mixed with 50126 and 50034 from the same IP	The same spray hitting live, disabled and non-existent names.
A disabled admin or service account tried from an unfamiliar IP	Someone has a credential for an account you retired. Find out where it came from.
A 50057 account that suddenly shows a success	The account was re-enabled. Check the audit log for who did it.

Because the account is disabled, sign-in stops at the credential stage. Expect ConditionalAccessStatus = notApplied on these rows, as Conditional Access only runs after the first factor succeeds.

How do I find it in my logs (KQL)?

One IP trying several disabled accounts in a day:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50057"
| summarize DisabledUsers = dcount(UserPrincipalName),
            Attempts = count(),
            Users = make_set(UserPrincipalName, 20),
            Clients = make_set(ClientAppUsed, 5)
          by IPAddress
| where DisabledUsers >= 3
| sort by DisabledUsers desc

What is still trying to use disabled accounts, interactive and non-interactive together:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50057"
| summarize Attempts = count(),
            FirstSeen = min(TimeGenerated),
            LastSeen = max(TimeGenerated),
            IPs = make_set(IPAddress, 10)
          by UserPrincipalName, AppDisplayName, ClientAppUsed, IsInteractive
| sort by LastSeen desc

The threshold of 3 in the first query is a starting point. Tune it to how many leavers you normally see.

How do Conditional Access and MFA affect it?

• Conditional Access does not evaluate a 50057. The account is refused before CA runs.
• AuthenticationRequirement on these rows says nothing about whether MFA is enforced in your tenant. MFA was never reached.
• Disabling the account blocks new sign-ins. It does not by itself cut tokens an app already holds. Microsoft’s revoke-access guidance pairs disabling the account with revoking sessions (Revoke-MgUserSignInSession) and notes that access tokens last one hour by default.

How do I fix AADSTS50057?

For the user: if you still need access, ask your admin. A disabled account is an admin decision, not a password problem. Remove old work accounts from personal phones and mail apps.

For admins:

1. If the account should be active, re-enable it. Microsoft’s description says an admin can do this through PowerShell. In hybrid tenants, re-enable it in on-premises AD and let it sync.
2. If it is a leaver, find the device or app in the second query and remove the account from it.
3. When you disable an account for offboarding or an incident, also revoke sessions.
4. If the first query shows a spray, check whether the same IP produced any success, 50076/50074 or 53003 for active accounts. Those accounts had a correct password.