Sharepoint Admin API Access page: "Error ensuring domain-wide principals"

[sam-cormack]

Target SharePoint environment

SharePoint Online

What SharePoint development model, framework, SDK or API is this about?

💥 SharePoint Framework

Developer environment

Windows

What browser(s) / client(s) have you tested

• [ ] 💥 Internet Explorer
• [X] 💥 Microsoft Edge
• [X] 💥 Google Chrome
• [ ] 💥 FireFox
• [ ] 💥 Safari
• [ ] mobile (iOS/iPadOS)
• [ ] mobile (Android)
• [ ] not applicable
• [ ] other (enter in the "Additional environment details" area below)

Additional environment details

• browser version
• SPFx version
• Node.js version
• etc

Describe the bug / error

I've uploaded an spfx app to the app catalog with Microsoft Graph permissions requested in package-solution.json. The app was uploaded successfully, but when I visit the Sharepoint Admin API Access page, the permission request does not load and I see the following error:

Error ensuring domain-wide principals: The application identifier uri 'api://148ec9e1-128a-4017-afd9-449afa449006/microsoft.spfx3rdparty.com' is invalid.

This is the first time I have uploaded an app that requests Microsoft Graph permissions. I believe the API Access page is trying to create a new App Registration for an app called "SharePoint Online Client Extensibility Web Application Principal". I can see it make a failed network request to "https://graph.microsoft.com/beta/applications/". It sends two identifierUris in the payload. One is the one from the error above, and one has my organisation's tenant ID and sharepoint domain. The ID 148ec9e1-128a-4017-afd9-449afa449006 from the error is not my tenant ID. I am logged in as a global administrator.

Steps to reproduce

1. Upload an app to the App Catalog that requires Microsoft Graph permissions for the first time
2. Go to the Sharepoint Admin Center API Access page

Expected behavior

The Microsoft Graph permission request for the app loads and can be approved.

[sam-cormack]

I am able to see the permission request via the PowerShell command Get-SPOTenantServicePrincipalPermissionRequests. There were a few other permissions requests from a third party app there too. I tried denying all the requests from Powershell to start fresh, but I still get the same error from the Sharepoint API access page.

[jacobmessner]

We are having the same issue. Following for updates...

[TehHota]

Same here

[jgsanw]

Getting this same error in our tenant.

If I try to approve the app requests via PowerShell using the Get-SPOTenantServicePrincipalPermissionRequests and Approve-SPOTenantServicePrincipalPermissionRequest cmdlets, I get an error that says the service principal for the request could not be found.

[mrwoes]

Same problem here. Already in contact with microsoft fore 2 months.... No results...

[Yin-ko]

Same, follwing for updates.

[mrwoes]

Is there an update? Let me know :)

[Yin-ko]

I think we were all hoping you might supply the update. :)

[mrwoes]

microsoft fixed it for us but did not gave a solution

[jacobmessner]

microsoft fixed it for us but did not gave a solution

We have a ticket open with Microsoft too. Would you be willing to provide your case number so that I can share it with them?

[tallday]

Seeing the same issue across multiple client sites. @VesaJuvonen can you provide any insight into this one? It makes for a very bad first time experience for clients installing an App from AppSource. Is the only solution to contact MS and wait weeks for a manual fix?

[tallday]

FWIW - shared on X https://x.com/TrentAllday/status/1802496060415422563

[VesaJuvonen]

We are actively looking into this. Thank you all for reporting and we'll work on getting this solved as soon as possible. I do apologize the delay on acknowledging it. Please do open up tickets using the official channel as you see it as well - as more tickets will mean also more focus. Not optimal, but trying to help to fix this efficiently.

[VesaJuvonen]

We do apologize the situation here and are using our internal routes to push on the resolution.

Please open support tickets in the tenant administrator channels in the admin UX - this is out of the box feature in the admin UX - which should be working without exceptions. If you have an option to open the support case with "Premier Support", please do that as it will help here as well.

The more reports we get through official channels - the faster we can get this resolved. Unfortunate situation for sure and using the official channels will help everyone. Thank you all.

[jacobmessner]

Microsoft was able to provide us with steps to resolve this issue. I believe our issue stemmed from us changing our tenant domain name. There was a url that the API access page uses that didn't get updated when we did this.

Not sure if this is the case for everyone else with this issue, but I figured maybe it will help someone.

Here are the steps Microsoft provided to us. They also provided us with a GUID of the app id that was causing problems. I'm not sure how others would find their respective app id.

1. Go to Graph Explorer and login. The URL is aka.ms/ge
2. Run the query https://graph.microsoft.com/v1.0/servicePrincipals?$filter=appid eq 'guid provided by MS support'
3. Confirm it does not have the above reply URI
4. Run a patch on https://graph.microsoft.com/v1.0/servicePrincipals/<ID from Query in step 2> with the body being all the current reply URI'S plus the missing one. ie: { "replyUrls":[ "https://yourdomain-admin.sharepoint.com/_forms/spfxsinglesignon.aspx", <Other Existing Reply URIs> ] }

[tallday]

Solved!! Thanks so much for the tip @jacobmessner

Here is a video on how you go about solving this problem (including my troubleshooting and delight in getting it working 🤣 )

https://www.loom.com/share/c10757775a514003aa8c697a41b9895d

The key missing part is clicking the link on the dev tools console to determine the app id. That app id relates to an enterprise app called 'SharePoint Framework Azure AD Helper' (which I had never seen before but must be responsible for provisioning 'SharePoint Online Client Extensibility Web Application Principal'). I then was able to determine the id of that app and patch it using Graph Explorer.

Its seems this tenant went through a name change at some stage and this part is not cleaned up as part of that rename process done by MS.

Thanks again. Hopefully this helps someone else from wasting hours and hours!

[mrwoes]

Hi, When you look up the app ID from Microsoft Support again, you will see that this app also has a name. Could you please tell me the name of this app?

[jacobmessner]

Hi @mrwoes,

I ran the query again and the appDisplayName was "SharePoint Framework Azure AD Helper"

Hope this helps!

[mrwoes]

Hello,

Thanks for your comment. Unfortunately, the app registration is set up correctly for us. Microsoft has also checked this. So that's not our problem...

[tallday]

I am also having an issue with another tenant getting this exact error reported initially in this post. My solution above doesnt resolve it. I'll keep you posted on any progress.

[mrwoes]

Any update?

[Yin-ko]

Figured my problem out today. Mircosoft had told me to manual create an App Registration, but didn't tell me what one I was supposed to create. In the Enterprise Application Audit Log I found a failure for SharePoint Framework Azure AD Helper trying to modify properties for SharePoint Online Client Extensibility Web Application Principal. Turned out I didn't have SharePoint Online Client Extensibility Web Application Principal, so I added it as the App Registration name from their instructions and everything started working immediately. Not sure its anyone else's issue, but the error I had was identical to OP.

[tallday]

@Yin-ko was there any specifics you needs to configure with the principle or was it just that the name matched?

[Yin-ko]

I was concerned I'd have to put together IDs but it only needed the correct name and it associated everything else automatically.

[tallday]

oh wow!! That was the easiest fix ever! Nice work @Yin-ko problem solved for me too.

[Yin-ko]

Glad to be of assistance.

[marcus-atvero]

I'm seeing the same problem with the calls to /beta/applications failing because the api URI is invalid.

I checked the helper principal and for me the reply URL was correct.

Deleteing and recreating the app looks like it works, but if you then refresh the API managemebt page and check the network traffic I see it making a PATCH on the second go still trying to set the incorrect APIs. This leaves us with a half built security principal and it also doesn't make the call to UpdateSpfxThirdPartyAppId to set the security principal ID.

What then happens is the SPFx looks like its working until it tries to get a token for making a Graph call, and fails because the scope of the token is set to the deleted principal.

We've only seen this on one tenancy out of 60, and a pretty old one, not sure how old you tenancies are?

We're stuck at the moment anyway.

[sam-cormack]

Deleteing and recreating the app looks like it works, but if you then refresh the API managemebt page and check the network traffic I see it making a PATCH on the second go still trying to set the incorrect APIs. This leaves us with a half built security principal and it also doesn't make the call to UpdateSpfxThirdPartyAppId to set the security principal ID.

This is basically where I got to before giving up. I manually created the App Registration in Entra, as per Yin-ko above. This let the Sharepoint Admin API permissions page load, but it still makes failed PATCH calls due to the invalid URI. I also tried updating the App Registration manually with the data from the failed calls, but the SPFx app still can't connect to the Graph API. I'm not familiar enough with SPFx to figure out why it's failing, but possibly the same reason as marcus-atvero. I did try going through Microsoft support, but never managed to get to someone who could figure out the issue.

[Yin-ko]

You might want to look in Enterprise Applications - Audit logs to see if there is a corresponding error to your problem.

[waaromikniet]

In my case the Enterprise Application SharePoint Online Client Extensibility Web Application Principal seemed correct. I did see a difference on the Expose an API page in the section Authorized client applications with a tenant that is working. I added the clientid's that are on my working tenant and the api access page started working again. I don't know if this fixes everything but I am investigating further.

The clientid's that were missing are

• 08e18876-6177-487e-b8b5-cf950c1e598c (SharePoint Online Web Client Extensibility)
• 00000003-0000-0ff1-ce00-000000000000 (Office 365 SharePoint Online)
• 1fec8e78-bce4-4aaf-ab1b-5451cc387264 (Microsoft Teams)
• 5e3ce6c0-2b1f-4285-8d4b-75ee78787346 (Microsoft Teams Web Client)

I noticed the difference when I came across this page: https://www.eliostruyf.com/fix-admin-consent-sp-token-retrieval-flows-spfx/