AADSTS50034: User account not found in the directory

What does AADSTS50034 mean?

UserAccountNotFound: To sign into this application, the account must be added to the directory. This error can occur because the user mis-typed their username, or isn’t in the tenant. An application might have chosen the wrong tenant to sign into, and the currently logged in user was prevented from doing so since they did not exist in your tenant. If this user should be able to log in, add them as a guest.

No account with that name exists in the tenant that received the request. No password check happened against a real account.

Is it an attack?

Microsoft’s description lists three benign causes: a typo, a user who isn’t in the tenant, and an app that picked the wrong tenant. Those explain most rows. The pattern decides:

Pattern	Likely meaning
One attempt, then a success with the corrected name from the same IP	A typo. Benign.
A user from a partner organisation, hitting one specific app	Wrong tenant or a missing guest invitation. Benign. Add them as a guest if they need access.
A former employee’s name, or a renamed user’s old name	Something still uses the old username. Find and update it.
Many different non-existent names from one IP	In practice, an attacker testing a user list: guessed firstname.lastname formats or a leaked list (T1087.004).
50034 mixed with 50126 and 50057 from the same IP	A password spray using a list that contains real, disabled and non-existent names (T1110.003).

Conditional Access does not apply here. There is no user for a policy to match, and CA only runs after the first factor succeeds. Expect ConditionalAccessStatus = notApplied.

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

One IP trying many non-existent usernames:

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "50034"
| summarize UnknownNames = dcount(UserPrincipalName),
            Attempts = count(),
            Sample = make_set(UserPrincipalName, 20),
            Apps = make_set(AppDisplayName, 5),
            Clients = make_set(ClientAppUsed, 5)
          by IPAddress
| where UnknownNames >= 10
| sort by UnknownNames desc

The same IPs, across all credential failures: how many real accounts were also hit, and did anything get through?

let enumIPs =
    SigninLogs
    | where TimeGenerated > ago(1d)
    | where ResultType == "50034"
    | summarize UnknownNames = dcount(UserPrincipalName) by IPAddress
    | where UnknownNames >= 10
    | project IPAddress;
SigninLogs
| where TimeGenerated > ago(1d)
| where IPAddress in (enumIPs)
| summarize Attempts = count(), Users = dcount(UserPrincipalName) by IPAddress, ResultType, ResultDescription
| sort by IPAddress asc, Attempts desc

Any ResultType of "0", "50076", "50074" or "53003" in the second result means a password was correct for at least one account. Pivot on that IP and user.

For a non-existent account, check which column holds the name that was typed. In practice it is usually UserPrincipalName. SignInIdentifier is documented as “populated when a user signs in using other identifiers”, so look there as well.

How do Conditional Access and MFA affect it?

• Conditional Access and MFA play no part in a 50034. The request fails before either is evaluated.
• The sign-in itself gives the attacker little, but the different answers do. A non-existent name returns 50034 and a real name with a wrong password returns 50126, so in practice the error alone can tell an attacker which names are real. The risk is the next step: the confirmed names get sprayed. Watch the same IPs for 50126 and 50053.

How do I fix AADSTS50034?

For the user: check the spelling of your username and that you are signing in with your work account. If you are from another organisation, ask the app owner to invite you as a guest.

For admins:

1. Single user: check for a typo, a renamed UPN, or an app pointing at the wrong tenant.
2. External user who needs access: add them as a guest (B2B), as Microsoft’s description says.
3. Enumeration pattern: you can’t block it at the Entra ID layer, because Conditional Access never evaluates a request for a user that doesn’t exist. Put the IP on a watchlist or threat-intel feed instead, and watch for follow-up 50126/50053 from the same range. If the names come in a predictable format, that is a hint your UPN convention is public.
4. Make sure every real account has MFA, so a list of valid names plus a sprayed password isn’t enough.