New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SPFx The user or administrator has not consented to use the application with ID '<guid>' named 'SharePoint Online Client Extensibility Web Application Principal' #2473
Comments
Edit: Scratch that, still doesn't work. |
The APIs trusted from https://tenant-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement ends up correctly in the "SharePoint Online Client Extensibility Web Application Principal" in AAD under Permissions as it should. I guess that the "SharePoint Online Client Extensibility Web Application Principal" is supposed to handle SPFx signins and therefor needs permissions to Sign in users from AAD granted globally and that this one lacks the grant that was previously globally deployed from Microsoft. Perhaps it was cleared when 1.6 was deployed and the grants were cleared? Can't debug since I don't have global admin (but have Application Admin and Cloud Application Admin) roles. Edit: So if I need to retrust this service principal - what permissions should it be granted? I need to send the list to a global admin at the customer who don't really have time to figure it out by trial and error :) (Edit delegated works, no global admin required) End of wild speculations Edit 2: Ok. So when adding and granting the below permissions to the SharePoint Online Client Extensibility Web Application Principal app registration it removed the API permission from the new SP admin center but added the AD permissions. So after a redeploy of the sspkg and a new trust we get: And after that everything seems to be smooth sailing. |
I believe this is the expected output based on the update to spfx 1.6. All granted permissions to AAD in SPO had to be re-granted per 1.6 release notes: https://github.com/SharePoint/sp-dev-docs/wiki/SharePoint-Framework-v1.6-release-notes |
@eoverfield agreed. I would be happy if one of the SP guys (@VesaJuvonen @lucaband @mcmynn83 @patmill ) could explain to me if this is indeed the normal process. Of if the application was for some reason created without this permission. And if it is expected it should definitely be added to the documentation. Just FYI this is my current "update documentation" (from SPFX 1.4.1 to my new SPFx 1.6 app):
|
@Nasicus It looks as though there are found issues and I am sure Microsoft will solve this. @VesaJuvonen provided more guidance here: #2472 (comment). Once this has been fixed, I am sure we will get instructions if anything needs to be done. |
@eoverfield I know they did, I read the other issue :) I just think these 2 errors/problems are not directly related. |
I think this is the answer you are looking for. With the move to GA, the new service principal that we create has 0 permissions. You will need to explicitly ask for the permissions you need. We did this so that over time, if the 1st party permissions change (say we add something, then remove it), you're code will continue to work as expected. Does that answer your question? |
This worked for me by adding the AAD User.Read permission in the "webApiPermissionRequests": [
{
"resource": "Windows Azure Active Directory",
"scope": "User.Read"
}
] (I am calling a custom Azure Function on behalf of the current user) Edit: Removed solution specific permissions. |
For now, you have to add User.Read to enable sign-in. By default, there is no permission granted for you. |
If we really have to ALWAYS add the permission
to the |
Can I suggest to go forward a step and add the permission to the |
@vman for my tenants that did not have any issues with the migration to 1.6, that included aad calls, I did not have to manually add user.read to the new service principal. I am trying to get us clarification if the requirement a few of us are having with the new service principal is actually a bug. |
Let me check around and I will follow up on this thread... OK, so it's a bit strange. This started happening in AAD, and we are following up with that team to figure out if it is expected. We think it doesn't make sense, but... For now, the workaround is to explicitly grand the permission as @Nasicus stated. We hope to get resolution quickly on this one way or another. If it turns out that in order to use the third party app for any call you need User.Read, then we will explicitly add that when the AAD app is created. It doesn't make sense for you folks to have to do anything in the long term. In the meantime, we'll update the documentation with the temporary work-around. |
@eoverfield didn't you say (#2472 (comment)) that you followed my steps to make it work? @patmill |
@Nasicus 's solution worked for us, thanks! |
@Nasicus I did use your process on two of my tenants and that did fix final issues I ran into. On a few other tenants, I never ran into issues with the recent updates, and I didn't have to follow your steps, the legacy solutions that utilized AAD continued to work. Very interesting. |
Solution by @Nasicus worked for me as well. It also was a combination of two issues - a user is not an admin, and "Windows Azure Active Directory" permission problem |
Fixed, thanks all, adding "webApiPermissionRequests": [ fixed it. |
This post shows the exact message I had, and why I even figured out to requiere this additional permission: #2480 (comment) |
Adding |
@olemp If you go to azure portal -> azure active directory -> enterprise applications -> switch drop down to Application Type - All -> search for "SharePoint Online Client Extensibility Web Application Principal" -> select it -> permissions -> does permission list contain |
@s-KaiNet My bad. An old access token was cached. Clearing localStorage and sessionStorage solved it for me (not sure which of them the client uses). |
Any idea why "SharePoint Online Client Extensibility web application Principle" not available in my tenant? Is there a way to enable "SharePoint Online Client Extensibility web application Principle" in a tenant? I am not able to remove the existing permissions in the API management I am getting "UnKnow Error." Even from the Powershell command to disable the "SharePoint Online Client Extensibility" I get same "UnKnow Error" Adding the permission "webApiPermissionRequests" on package bring the permission in the "API manager" but when i try to approve it give "UnKnow Error", I suspect it becuse the API Manger is associated with the "SharePoint Online Client Extensibility web application Principle", becuse the principle is missing, the Permission request could not be updated. |
Original issue has been fixed and you need to re-approve your permissions. This is either related on the #2472 or related on the missing approvals of the permissions. @DnsSrinath - your issue seems same as #2522, if that's not the case, please open a new issue and provide needed details. Thx. |
I just want to add, that I had the same issues and the solution was quiet simple: |
Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues |
Category
Expected or Desired Behavior
AadHttpClient should work according to previous (1.5 plus version)
Observed Behavior
Deployed and trusted webApiPermissions requested by app onto a production environment with no targeted release.
Ran o365$
spo serviceprincipal set -e true
SharePoint Online Client Extensibility Web Application Principal exists in https://portal.azure.com/#blade/Microsoft_AAD_IAM/ActiveDirectoryMenuBlade/RegisteredApps with matching from above. Redeployed solutions and re-trusted API.
Recieve console message below from SPFx solution
Response from: /_forms/spfxsinglesignon.aspx#error=interaction_required&error_description=AADSTS65001%3a+The+user+or+administrator+has+not+consented+to+use+the+application+with+ID
The text was updated successfully, but these errors were encountered: