Azure Active Directory, the advanced logo

AADSTS50011 – The resource principal named was not found in the tenant | An easy fix!

This post was most recently updated on June 23rd, 2022.

3 min read.

Another day, another variant of AADSTS50011! With a lot of apps and web services using Azure Active Directory for authentication, you’re bound to run into issues, right?

Ah well, one would hope to avoid them. But at least this one is usually easy to fix!

Let’s first take a closer look at the different versions of the error you might face, and then see how we can fix or avoid them altogether!

Problem

I’ve encountered 2 different variants of this particular issue – the error message may or may not contain the name of the principal it’s looking for, and the Guid of the tenant it’s looking for the principal in.

AADSTS500011 – The resource principal named was not found in the tenant.

Or

AADSTS500011 – The resource principal named [URI] was not found in the tenant named [guid]. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.

Or, the worst of all, you might be greeted with an empty page or pop-up, with the URL being something like this:

https://contoso.sharepoint.com/_layouts/images/blank.gif#error=invalid_resource&error_description=AADSTS500011%3a+The+resource+principal+named+[your-app-name-here]+was+not+found+in+the+tenant+named+[AAD-tenant-guid-here].+This+can+happen+if+the+application+has+not+been+installed+by+the+administrator+of+the+tenant+or+consented+to+by+any+user+in+the+tenant.+You+might+have+sent+your+authentication+request+to+the+wrong+tenant.%0d%0aTrace+ID%3a+1aaa8b90-afd9-4aba-afc4-206aa5850d00%0d%0aCorrelation+ID%3a+04c96fe2-3cba-4db2-aab3-8e92b1c2e50f%0d%0aTimestamp%3a+2019-03-20+08%3a28%3a44Z

But what gives?

Solutions & workarounds

There are a couple of possible reasons for this particular variant of the error. Let’s go through them together, shall we?

First of all, maybe it’s true. Maybe the application, website, or service you’re logging in to is trying to log in to the wrong Azure AD instance, or it’s logging in to the right Azure AD, but it’s a multi-tenant application that hasn’t been consented to by the administrator at the said tenant.

Let’s go through the steps below to verify the configuration is correct! Each step also comes with proposed workarounds or solutions.

Time needed: 30 minutes.

How to fix the AADSTS500011 “The resource principal named was not found in the tenant” -error?

  1. Verify, that the request really went to the right tenant!

    You can see the tenant Id in the error message. Verify that it’s YOUR tenant (or the one you’re using for this scenario anyway).

    Not sure how to find out the id of your Azure AD? This blog post should help:
    How to find out the Directory ID of your Azure AD tenant?

    If the tenant ids don’t match, the application is either misconfigured, in which case you need to change the configuration of your authentication provider, or…

  2. The application is trying to reuse your existing log-in or otherwise trying to dynamically figure out the right tenant to log in against, and failing

    Wow, where to even begin with this one?

    I suppose this one more or less falls under “misconfiguration” as well, but if the authentication parameters are being configured at runtime, it’s possible that the authentication requests are sent to the wrong Azure AD instant because of your existing cookies.

    Try clearing your cookies or opening an incognito/private browsing session, and see if the problem persists.

  3. It’s the right AAD, but the app isn’t there

    In case it’s an enterprise application, verify that registering applications is allowed on the tenant.

    In case it’s not an enterprise application, register your app on the tenant.

    Microsoft has decent documentation on these scenarios!

  4. It’s the right AAD and application, but you’re missing your required scopes

    Like Mrobo and Fenrir point out in the comments-section below, AADSTS50011 can also be thrown if you’re missing the right scopes from your request. Make sure to verify them as well.

  5. It’s the right AAD and the app is there but hasn’t been consented to

    If you’re trying to log in from an application that doesn’t support user consent flow or you’re unable to use it otherwise, you can use the same special login URL crafting trick that I proposed in my article for resolving consent-related issues when getting error AADSTS650001, and create a URL like this:

    https://login.microsoftonline.com/[tenant_name_in_onmicrosoft.com-form]/oauth2/authorize?client_id=[appId]&response_type=code&redirect_uri=http://your-uri-here&nonce=1234&resource=https://graph.windows.net&prompt=consent

    If the application requires admin consent, replace “consent” with “admin_consent”.

  6. Is this multi-tenant/enterprise application not present in your tenant?

    The configuration for enterprise applications can be a bit confusing and there are a lot of steps that could go wrong. While you’d typically get an AADSTS650001 error for this, it might still be worthwhile recruiting your local Global Administrator to try logging in instead.

  7. Using a URI as a resource principal?

    In case your application id is a URI and not a Guid, verify you’ve written it properly. It doesn’t need to be a valid domain – it just needs to match the URI configured for your application!


I think that’s all I had for today. Still, having issues? Ping me in the comments -section below!

mm
4.8 5 votes
Article Rating
Subscribe
Notify of
guest

4 Comments
most voted
newest oldest
Inline Feedbacks
View all comments