AADSTS51004 fix: user account not in the directory

What does AADSTS51004 mean?

Microsoft’s description:

UserAccountNotInDirectory: The user account doesn’t exist in the directory. An application likely chose 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. For further information, please visit add B2B users.

The user is known somewhere, but not in the tenant this sign-in went to. Microsoft’s first guess is an app that sent the user to the wrong tenant.

The message users see reads like this example from Microsoft Q&A: “AADSTS51004: The user account {id} does not exist in the {tenant ID} directory. To sign into this application, the account must be added to the directory.” The tenant ID in the message tells you which directory was asked.

51004 or 50034?

The wording is almost the same, so the code is what tells them apart. 50034 (UserAccountNotFound) is the one Microsoft ties to a mistyped username. When a token request was sent for a username that doesn’t exist in a lab tenant, Entra returned 50034, not 51004 (see the 50034 page). Microsoft’s 51004 description talks about “the currently logged in user”. Our reading: 51004 tends to come after the user has already been identified, by their home tenant or by a federated identity provider, and Entra then can’t find a matching account in the target tenant. 50034 is the plain “no such username” answer. Microsoft doesn’t document the split in those words.

50020 is a close neighbour too: an account from another identity provider that isn’t a user or guest in the tenant. Both point to the same fix for outside users: add them as a guest.

Is it an attack?

Usually not. Our reading: the user has already proven who they are somewhere; they just aren’t in this directory.

Pattern	Likely meaning
A user from another organisation opening your app, or Teams switching into your tenant	Wrong tenant or no guest account. Users report this often in Teams and other Microsoft 365 apps. Benign. Invite them as a guest if they need access.
Users of a federated domain (Okta, Google Workspace, other SAML IdP) failing after the IdP login	The IdP authenticated them, but no Entra user matches what the IdP sent. Okta and Microsoft Q&A users report this. A provisioning or ImmutableId problem, not an attack.
New hires failing while existing users work, on a federated domain	The account was created at the IdP but never provisioned to Entra ID.
A former employee or a renamed user	Something still uses the old identity. Find and update it.

Unlike 50034, there is no documented enumeration pattern for 51004. Our reading is that it has low value for an attacker testing usernames, because it follows a sign-in that already happened somewhere else. A burst of 51004 for many different users from one IP is still worth a look; the KQL below finds it.

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

Microsoft doesn’t document which sign-in table 51004 lands in. Check where it lands:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(7d)
| where ResultType == "51004"
| summarize Rows = count(), Users = dcount(UserPrincipalName) by SourceTable

Which apps send users to a tenant they’re not in, and where the users come from:

SigninLogs
| where TimeGenerated > ago(30d)
| where ResultType == "51004"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            SampleUsers = make_set(UserPrincipalName, 10),
            HomeTenants = make_set(HomeTenantId, 5),
            Protocols = make_set(AuthenticationProtocol, 3)
          by AppDisplayName, AppId
| sort by Users desc

Many different accounts from one IP, the shape worth a second look (10 is a starting point; tune it to your tenant):

SigninLogs
| where TimeGenerated > ago(1d)
| where ResultType == "51004"
| summarize Accounts = dcount(UserPrincipalName),
            Attempts = count(),
            Sample = make_set(UserPrincipalName, 20)
          by IPAddress
| where Accounts >= 10
| sort by Accounts desc

For a user who doesn’t exist in the tenant, which column holds the name is not documented. UserPrincipalName is a reasonable first guess; also check SignInIdentifier. A federated domain with many 51004 rows from your own egress IPs points at provisioning, not an attacker. ResultType is a string column, so compare it with "51004".

How does Conditional Access affect it?

• Our reading: Conditional Access plays no part, because there is no user object in the tenant for a policy to match.
• If the user is later added as a guest, the target tenant’s Conditional Access policies apply to them from then on.

How do I fix AADSTS51004?

For the user: check that you are signed in with the right account. In Teams or a browser with several accounts, sign out and sign in again with the account your organisation gave you. If you are from another organisation, ask the app owner to invite you as a guest.

For developers: check which tenant your app sends users to. Likely, but not documented: an app hard-wired to one tenant ID sends outside users there, and they fail. Use the tenant the user belongs to, or ask the tenant owner to invite them.

For admins:

1. External user who needs access: add them as a guest, as Microsoft’s description says. In the Entra admin center (at least User Administrator): Users > New user > Invite external user. Microsoft notes “The guest user must then redeem their invitation to access resources.”
2. Federated domain (Okta, Google Workspace, other SAML IdP): the user must exist in Entra ID first. Microsoft’s federated sign-in docs for Windows devices state that “each Google Workspace user requires a matching account defined in Microsoft Entra ID”, and that Entra “searches for a matching user object in the tenant by using an attribute called ImmutableId”. The match is case-sensitive. Check the account exists and that its OnPremisesImmutableId matches what the IdP sends. Okta’s KB describes this exact mismatch as a cause of 51004.
3. New users failing only: check provisioning from the IdP actually created them in Entra ID.
4. Renamed or removed user: find what still uses the old identity and update it.