AADSTS500011: How to associate a resource principal with an application client ID

asked 2021-04-28T02:35:13.977+00:00
Benjamin Li-Sauerwine 1 Reputation point

I am setting up an enterprise application where third-party applications should be able to authenticate into it using our institutional SSO. The enterprise application has a GUID Client ID provided (e.g., 12345678-1234-1234-1234-1234567890ab) and I am indeed able to log into the application both through the public URL (e.g., https://myapp.myinstitution.edu) and using applications under my control that are aware of the Client ID.

The issue comes when I try to log into it with a third-party application like PowerBI. PowerBI, being outside my control, does not know the Client ID and attempts to log in using the public URL as the resource principal (https://myapp.myinstitution.edu).

My assumption is that somewhere I need to inform Azure Active Directory that the resource principal known to third-party apps (e.g., https://myapp.myinstitution.edu) is one and the same as my client ID (e.g., 12345678-1234-1234-1234-1234567890ab). My belief was that the correct way to do this would be to configure a Publisher Domain under the Branding section under App Registrations, but this did not resolve the issue.

How do I inform Active Directory that certain resource principals are synonymous with my application's Client ID?

Azure Active Directory
Azure Active Directory
An Azure enterprise identity service that provides single sign-on and multi-factor authentication.
12,583 questions
{count} votes

2 answers

Sort by: Most helpful
  1. answered 2022-12-13T09:19:43.343+00:00
    Gwen Demulder 1 Reputation point

    Hi BenjaminLiSauerwine-6547,

    Were you ever able to resolve this issue?
    I'm having the identical problem with an app-service and power bi desktop.

    No comments

  2. answered 2022-12-13T09:44:17.757+00:00
    Benjamin Li-Sauerwine 1 Reputation point

    I apologize that it's been so long since I've encountered this issue that I may have forgotten some important details. Further, checking my e-mail history, not all of what was done on the institutional AD admin side was ever made clear to me.

    As far as I can tell looking at the Active Directory application (which in my case was an instance of HAPI FHIR connecting to PowerBI's FHIR connector), this is what needs to happen:

    In Azure AD App Registrations:

    1. Under "Branding and Properties", set your Home Page URL to, e.g., https://yourapplication.yourdomain.com
    2. Again under "Branding and Properties," go to Publisher Verification. Hit "Verify a New Domain" and get your domain verified by your institution's AD admin.
    3. Under "Authentication", set the appropriate callback URLs.
    4. Under "API Permissions," get admin consent for Microsoft. Graph > Directory.Read.All, email, openid, profile, and User.Read
    5. Under "Expose an API", get admin consent for https://yourapplication.yourdomain.com/user_impersonation

    Not all of that may be strictly necessary, but those are the steps I can reconstruct from my e-mail and is all that is directly visible in my AD application.

    If that still doesn't work, there was one additional note I found in the e-mail thread, which was that the AD admin had to consent for "Power Query for Excel" also. I can't find any evidence that this actually happened in Azure Portal, though, so your mileage there may vary.

    No comments