AADSTS50057 (UserDisabled): Sign-In to a Disabled Account

What it means

Entra ID found the account — so unlike AADSTS50034, the name is real — and refused the sign-in because the account object is disabled. Microsoft’s wording is that “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”. In a hybrid tenant the disabled state normally originates on the on-premises user object and arrives through directory synchronisation; in a cloud-only tenant it is set directly on the Entra ID user.

What the code does not tell you is whether the password that was submitted was correct. The failure reason is about the state of the account, not about the credentials, so a 50057 is neither proof that the password was wrong nor proof that it worked. That is why the source matters more than the count here.

Is it an attack?

Pattern	Reading
One disabled account, failures at regular intervals from an internal host or office IP	Leftover stored credential — a service, scheduled task, mapped drive or mail profile that was never cleaned up at offboarding
One leaver’s account from a residential, mobile or VPN address, a few times a day	The former employee still has the password saved, or someone else does
50057 mixed with AADSTS50034 and AADSTS50126 from one source across many names	Spraying or stuffing against a stale list; the 50057 entries are the names that were real
50057 for a privileged or break-glass-adjacent account from anywhere unfamiliar	Treat as targeted — someone knows which account used to hold that role
50057 for an account, then a success for the same account days later	The account was re-enabled. Confirm who did it and why (T1098)

Legacy authentication protocols are worth checking on every one of these, because clients that cannot be challenged are exactly what stored-credential and spraying activity tends to use — see the legacy-auth MFA bypass rule.

How to investigate

Start with which disabled accounts are still being used and by what:

SigninLogs
| where TimeGenerated > ago(14d)
| where ResultType == "50057"
| summarize Attempts = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated),
            Apps = make_set(AppDisplayName, 10), Clients = make_set(ClientAppUsed, 10),
            Sources = make_set(IPAddress, 20), Where = make_set(Location, 10)
    by UserPrincipalName
| order by Attempts desc

Run the same query against AADNonInteractiveUserSignInLogs; background clients retrying an old password rarely show up in the interactive table.

Then pivot to the source and answer the question that sets the severity — did that address ever succeed for anything?

let lookback = 14d;
let wins = SigninLogs
    | where TimeGenerated > ago(lookback) and ResultType == "0"
    | summarize Successes = count(), SucceededFor = make_set(UserPrincipalName, 20) by IPAddress;
SigninLogs
| where TimeGenerated > ago(lookback) and ResultType == "50057"
| summarize DisabledHits = count(), DisabledAccounts = dcount(UserPrincipalName),
            AccountList = make_set(UserPrincipalName, 20), Clients = make_set(ClientAppUsed, 5)
    by IPAddress, Location
| join kind=leftouter wins on IPAddress
| where DisabledAccounts > 1
| project IPAddress, Location, DisabledHits, DisabledAccounts, AccountList, Clients,
          Successes, SucceededFor
| order by DisabledAccounts desc

If the source is internal and the pattern is clockwork, find the host and clear the saved credential. If it is external, confirm the account is still meant to be disabled, review the directory audit log for any change that re-enabled it or altered its authentication methods, and check whether the same IP appears against live accounts with AADSTS50126 or AADSTS50053 — that turns one stale-account failure into evidence of a wider spray.