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 January 28th, 2024.

4 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!

AI-powered summary: AADSTS50011 – How to resolve the resource principal not found error in Azure AD

This article explains the AADSTS50011 error, which occurs when Azure AD authentication fails due to invalid reply URLs or consent issues. The error can have different variants and causes, such as:

  • The application is logging in to the wrong Azure AD tenant
  • The application is using dynamic authentication parameters that conflict with existing cookies
  • The application is not registered or consented to in the Azure AD tenant
  • The application is missing the required scopes in the authentication request
  • The application is using a URI as a resource principal that does not match the configuration

The article provides easy solutions for each of these scenarios, such as:

  • Verifying and updating the reply URLs for the app
  • Clearing cookies or using incognito mode
  • Registering or consenting to the app in the Azure AD tenant
  • Adding the correct scopes to the authentication request
  • Using the proper URI format for the resource principal


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.


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.

Yes, it really does say “tenant named 123e4567-e89b-12d3-a456-426614174000″. But you probably didn’t name your tenant a character soup like that – that’s the actual tenant id, a guid that uniquely identifies your tenant.

Back to the error messages – the worst of all, you might be greeted with an empty page or pop-up, with the URL being something like this:[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

Yay! Clear as mud. 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:[]/oauth2/authorize?client_id=[appId]&response_type=code&redirect_uri=http://your-uri-here&nonce=1234&resource=

    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!

4.9 7 votes
Article Rating
Notify of

most voted
newest oldest
Inline Feedbacks
View all comments