AADSTS90019 fix: no tenant found in the sign-in request

What does AADSTS90019 mean?

Microsoft’s description:

MissingTenantRealm: Microsoft Entra ID was unable to determine the tenant identifier from the request.

The message users post is longer: “No tenant-identifying information found in either the request or implied by any provided credentials.” Entra ID didn’t know which organisation’s directory to use, so, our reading, it stopped before checking anything else.

Entra ID gets the tenant from one of two places:

• The URL. In the authority https://login.microsoftonline.com/<tenant>/, Microsoft says “the <tenant> in the URL is the tenant ID of the Microsoft Entra tenant (a GUID), or its tenant domain.”
• The user. On the common sign-in page users “enter a user principal name (UPN). Microsoft Entra ID uses this information to determine the correct sign-in location.” Microsoft calls this Home Realm Discovery.

Our reading: 90019 is what you get when neither source gives an answer. The request went to common or organizations, and there was no username with a known domain, no hint, and no credential that points at a tenant.

Don’t confuse it with two codes that already have pages. 90002 means a tenant value was sent but no such tenant exists. 900023 means the tenant value isn’t a valid tenant ID or domain at all. With 90019 there was no tenant value to check.

Is it an attack?

Rarely. Our reading: the request fails before any user, password or app in your tenant is looked at. Users report it in ordinary situations:

• A university helpdesk sees it when students sign in to Outlook. Their advice is to enter the full email address, retype saved credentials, and try another browser or a private window.
• TheWindowsClub reports it for Office 365 and Skype for Business sign-ins.
• Quest has a knowledge base entry for it in Essentials for Office 365, a migration tool, which suggests admin tools and integrations hit it too.

Pattern	Likely meaning
One user, one app, then a success	The user typed a short username or a saved credential was wrong. Benign.
Every run of a script or service fails	The script sends an app-only request to common or organizations. A developer error.
A third-party federation or migration tool fails for everyone	The tool’s tenant or domain setting is empty or wrong. Configuration.

Our reading: since Entra ID didn’t find a tenant, it may not write the failure to your tenant’s sign-in log at all. Microsoft doesn’t document this. An empty result from the queries below doesn’t prove users aren’t hitting it; ask them for the error page details.

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

Microsoft doesn’t document which sign-in table 90019 lands in, or whether it reaches a tenant’s log at all. Check your workspace:

union withsource=SourceTable SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "90019"
| summarize Rows = count(), Apps = dcount(AppId) by SourceTable

If rows exist, see which app, client and user agent produce them:

union SigninLogs, AADNonInteractiveUserSignInLogs
| where TimeGenerated > ago(30d)
| where ResultType == "90019"
| summarize Rows = count(),
            Users = dcount(UserPrincipalName),
            Clients = make_set(ClientAppUsed, 5),
            Agents = make_set(UserAgent, 5),
            FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
          by AppDisplayName, AppId
| sort by Rows desc

ResultType is a string column, so compare it with "90019", not 90019.

How do I fix AADSTS90019?

For the user:

1. Sign in with your full work email address (for example [email protected]), not just your username. Entra ID uses the domain part to find your organisation.
2. If a password manager or the app filled in the name, retype it yourself.
3. Users report that a private browser window, clearing the browser cache, or another browser also helps. If none of that works, send your IT helpdesk the error details.

For developers:

1. If your app serves one organisation, put the tenant ID (GUID) or a verified domain in the authority: https://login.microsoftonline.com/<tenant>/.
2. For app-only requests (client credentials), the token request needs a tenant. Microsoft’s reference marks tenant as Required: “The directory tenant the application plans to operate against, in GUID or domain-name format.”
3. For a multitenant app on common or organizations, give Entra ID a way to find the tenant: a login_hint with the user’s address, or a domain hint. Microsoft lists the domain hint per protocol: domain_hint for OpenID Connect, whr for WS-Federation, and a domain hint or whr for SAML.

For admins:

1. For a third-party tool or federation service (a migration tool, a WS-Federation identity provider), check that its tenant or domain setting is filled in with your tenant ID or a verified domain.
2. Check that users’ sign-in names use a domain verified in your tenant. Microsoft notes that sign-in uses “organization and user settings for the username entered on the sign-in page.”