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

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!