Azure Active Directory, the advanced logo

How to fix “AADSTS50011 – The resource principal named was not found in the tenant”

Reading Time: 4 minutes.

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!

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’s a couple of possible reasons for this particular variant of the error. Let’s go trough 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 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 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 is 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 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://&nonce=1234&resource=https://graph.windows.net&prompt=consent

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

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

    The configuration for enterprise applications can be a bit confusing and there’s 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.

  6. Using a URI as resource principal?

    In case your application id is an 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
0 0 vote
Article Rating
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments