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

Closed
pbjorklund opened this Issue Sep 6, 2018 · 25 comments

Comments

Projects
None yet
@pbjorklund
Contributor

pbjorklund commented Sep 6, 2018

Category

  • Question
  • Typo
  • Bug
  • Additional article idea

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

Uncaught (in promise) Error: AADSTS65001: The user or administrator has not consented to use the application with ID '1565f76c-d88e-4586-9d23-9ef27af612c3' named 'SharePoint Online Client Extensibility Web Application Principal'. Send an interactive authorization request for this user and resource.
Trace ID: 0b113a29-86da-4039-96c6-01880a440100
Correlation ID: 8fac6554-c3a2-40d4-9cfd-ba99f5a89408
Timestamp: 2018-09-06 08:06:29Z
    at Array.<anonymous> (sp-pages-assembly_en-us_2fd01d9d9722e6b700aca2046e1c70ae.js:988)
    at _callBackMappedToRenewStates.(anonymous function)._callBackMappedToRenewStates.(anonymous function) (https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-08-27.007/1.sp-http-adal_58855c41adb591deebd1.js:3:7561)
    at AuthenticationContext.handleWindowCallback (VM96 adal.min.js:2)
    at parseTokenFromUrl (spfxsinglesignon.aspx:20)
    at onload (VM160 spfxsinglesignon.aspx:31)

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

@pbjorklund

This comment has been minimized.

Show comment
Hide comment
@pbjorklund

pbjorklund Sep 6, 2018

Contributor

Edit: Scratch that, still doesn't work.

Contributor

pbjorklund commented Sep 6, 2018

Edit: Scratch that, still doesn't work.

@pbjorklund

This comment has been minimized.

Show comment
Hide comment
@pbjorklund

pbjorklund Sep 6, 2018

Contributor

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.
image

So after a redeploy of the sspkg and a new trust we get:

image

And after that everything seems to be smooth sailing.

Contributor

pbjorklund commented Sep 6, 2018

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.
image

So after a redeploy of the sspkg and a new trust we get:

image

And after that everything seems to be smooth sailing.

@eoverfield

This comment has been minimized.

Show comment
Hide comment
@eoverfield

eoverfield Sep 6, 2018

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 commented Sep 6, 2018

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

@Nasicus

This comment has been minimized.

Show comment
Hide comment
@Nasicus

Nasicus Sep 6, 2018

@eoverfield agreed.
The bug / strange thing here is for me that we manually need to give the Windows Azure Active Directory permission Sing and read user profile to the automatically created application SharePoint Online Client Extensibility Web Application Principal.
This is (as far as I could see) not documented anywhere.

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):

  - Go to the "API Management"-section in the SharePoint Preview Admin Center (https://TENANT-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement)
  - Ensure that no permissions are there anymore 
  - Head over to the App Registrations Page in the Azure Portal.
  - Click "View all applications"
  - Click "SharePoint Online Client Extensibility Web Application Principal"
  - Choose "Settings" > "Required Permissions"
  - Click "Add"
    - "Select an API" and choose "Windows Azure Active Directory", press "Select"
    - "Select Permissions" and choose "Sign in and read user profile", press "Select"
  - Click "Done"
  - Click "Grant permissions" and "Yes"
  - Update the app package in the app catalog
  - Head back to the "API Managment"-section:
    - Ensure that "Windows Azure Active Directory" is already listed in the approved permissions (this permission should be here because of the previously executed steps).
    - Approve all permission requests one by one. Once this is done, reload the page to ensure that all permissions are actually approved as the SharePoint UI doesn't always behave as expected.
  - Wait a couple of minutes
  - Log out of SharePoint, close all browser windows and log in again
  - Access your intranet and everything should be fine

Nasicus commented Sep 6, 2018

@eoverfield agreed.
The bug / strange thing here is for me that we manually need to give the Windows Azure Active Directory permission Sing and read user profile to the automatically created application SharePoint Online Client Extensibility Web Application Principal.
This is (as far as I could see) not documented anywhere.

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):

  - Go to the "API Management"-section in the SharePoint Preview Admin Center (https://TENANT-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/webApiPermissionManagement)
  - Ensure that no permissions are there anymore 
  - Head over to the App Registrations Page in the Azure Portal.
  - Click "View all applications"
  - Click "SharePoint Online Client Extensibility Web Application Principal"
  - Choose "Settings" > "Required Permissions"
  - Click "Add"
    - "Select an API" and choose "Windows Azure Active Directory", press "Select"
    - "Select Permissions" and choose "Sign in and read user profile", press "Select"
  - Click "Done"
  - Click "Grant permissions" and "Yes"
  - Update the app package in the app catalog
  - Head back to the "API Managment"-section:
    - Ensure that "Windows Azure Active Directory" is already listed in the approved permissions (this permission should be here because of the previously executed steps).
    - Approve all permission requests one by one. Once this is done, reload the page to ensure that all permissions are actually approved as the SharePoint UI doesn't always behave as expected.
  - Wait a couple of minutes
  - Log out of SharePoint, close all browser windows and log in again
  - Access your intranet and everything should be fine
@eoverfield

This comment has been minimized.

Show comment
Hide comment
@eoverfield

eoverfield Sep 6, 2018

@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 commented Sep 6, 2018

@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.

@Nasicus

This comment has been minimized.

Show comment
Hide comment
@Nasicus

Nasicus Sep 6, 2018

@eoverfield I know they did, I read the other issue :) I just think these 2 errors/problems are not directly related.
I migrated/installed quite a few tenants today.
My approach was always the same (see my post above). This worked for almost all tenants, expect where I had this exception (which they are indeed investigating right now). But having to give permission to the SPFx principal app seems like a separate issue to me, that's why I wanted to show it to them :)

Nasicus commented Sep 6, 2018

@eoverfield I know they did, I read the other issue :) I just think these 2 errors/problems are not directly related.
I migrated/installed quite a few tenants today.
My approach was always the same (see my post above). This worked for almost all tenants, expect where I had this exception (which they are indeed investigating right now). But having to give permission to the SPFx principal app seems like a separate issue to me, that's why I wanted to show it to them :)

@patmill

This comment has been minimized.

Show comment
Hide comment
@patmill

patmill Sep 6, 2018

Contributor

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?

Contributor

patmill commented Sep 6, 2018

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?

@vman

This comment has been minimized.

Show comment
Hide comment
@vman

vman Sep 6, 2018

Contributor

This worked for me by adding the AAD User.Read permission in the package-solution.json and then re-uploading the solution to the App Catalog and then granting the permissions again from the API Management page:

"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.

Contributor

vman commented Sep 6, 2018

This worked for me by adding the AAD User.Read permission in the package-solution.json and then re-uploading the solution to the App Catalog and then granting the permissions again from the API Management page:

"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.

@qz2017

This comment has been minimized.

Show comment
Hide comment
@qz2017

qz2017 Sep 7, 2018

For now, you have to add User.Read to enable sign-in. By default, there is no permission granted for you.

https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes#PermissionScopeDetails

qz2017 commented Sep 7, 2018

For now, you have to add User.Read to enable sign-in. By default, there is no permission granted for you.

https://msdn.microsoft.com/Library/Azure/Ad/Graph/howto/azure-ad-graph-api-permission-scopes#PermissionScopeDetails

@Nasicus

This comment has been minimized.

Show comment
Hide comment
@Nasicus

Nasicus Sep 7, 2018

@patmill

If we really have to ALWAYS add the permission

      {
        "resource": "Windows Azure Active Directory",
        "scope": "User.Read"
      }

to the webApiPermissionRequests, then this really has to be added to the documentation:
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient

Nasicus commented Sep 7, 2018

@patmill

If we really have to ALWAYS add the permission

      {
        "resource": "Windows Azure Active Directory",
        "scope": "User.Read"
      }

to the webApiPermissionRequests, then this really has to be added to the documentation:
https://docs.microsoft.com/en-us/sharepoint/dev/spfx/use-aadhttpclient

@vman

This comment has been minimized.

Show comment
Hide comment
@vman

vman Sep 7, 2018

Contributor

Can I suggest to go forward a step and add the permission to the package-solution.json through the SPFx generator itself? If it is going to be needed in all cases, makes sense to have it in the default scaffolding.

Contributor

vman commented Sep 7, 2018

Can I suggest to go forward a step and add the permission to the package-solution.json through the SPFx generator itself? If it is going to be needed in all cases, makes sense to have it in the default scaffolding.

@eoverfield

This comment has been minimized.

Show comment
Hide comment
@eoverfield

eoverfield Sep 7, 2018

@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.

eoverfield commented Sep 7, 2018

@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.

@patmill

This comment has been minimized.

Show comment
Hide comment
@patmill

patmill Sep 7, 2018

Contributor

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.

Contributor

patmill commented Sep 7, 2018

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.

@Nasicus

This comment has been minimized.

Show comment
Hide comment
@Nasicus

Nasicus Sep 7, 2018

@eoverfield didn't you say (#2472 (comment)) that you followed my steps to make it work?
Because then you did the same thing,but instead of via the manifest you did it via the App directly (which I think is probably the "wrong" way).

@patmill
The reason I figured even out to give this permission is because, after I deployed my app with my "normal permissions", approved them and went to the page where my app is used I had the explicit message that "At least Azure Active Directory "Sign in and Read User Profile" is required".

Nasicus commented Sep 7, 2018

@eoverfield didn't you say (#2472 (comment)) that you followed my steps to make it work?
Because then you did the same thing,but instead of via the manifest you did it via the App directly (which I think is probably the "wrong" way).

@patmill
The reason I figured even out to give this permission is because, after I deployed my app with my "normal permissions", approved them and went to the page where my app is used I had the explicit message that "At least Azure Active Directory "Sign in and Read User Profile" is required".

@baywet

This comment has been minimized.

Show comment
Hide comment
@baywet

baywet Sep 7, 2018

Contributor

@Nasicus 's solution worked for us, thanks!

Contributor

baywet commented Sep 7, 2018

@Nasicus 's solution worked for us, thanks!

@eoverfield

This comment has been minimized.

Show comment
Hide comment
@eoverfield

eoverfield Sep 7, 2018

@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.

eoverfield commented Sep 7, 2018

@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.

@s-KaiNet

This comment has been minimized.

Show comment
Hide comment
@s-KaiNet

s-KaiNet Sep 8, 2018

Contributor

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

Contributor

s-KaiNet commented Sep 8, 2018

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

@iainl

This comment has been minimized.

Show comment
Hide comment
@iainl

iainl Sep 10, 2018

Fixed, thanks all, adding

"webApiPermissionRequests": [
{
"resource": "Windows Azure Active Directory",
"scope": "User.Read"
}
]

fixed it.

iainl commented Sep 10, 2018

Fixed, thanks all, adding

"webApiPermissionRequests": [
{
"resource": "Windows Azure Active Directory",
"scope": "User.Read"
}
]

fixed it.

@Nasicus

This comment has been minimized.

Show comment
Hide comment
@Nasicus

Nasicus Sep 10, 2018

@patmill

This post shows the exact message I had, and why I even figured out to requiere this additional permission: #2480 (comment)

Nasicus commented Sep 10, 2018

@patmill

This post shows the exact message I had, and why I even figured out to requiere this additional permission: #2480 (comment)

@olemp

This comment has been minimized.

Show comment
Hide comment
@olemp

olemp Sep 11, 2018

Adding Windows Azure Active Directory scope User.Read fixed the original issue, but I'm still getting a Authorization_RequestDenied response from https://graph.microsoft.com/v1.0/groups using the new MSGraphClient. I've granted the permission scope Group.ReadWrite.All for Microsoft Graph.

olemp commented Sep 11, 2018

Adding Windows Azure Active Directory scope User.Read fixed the original issue, but I'm still getting a Authorization_RequestDenied response from https://graph.microsoft.com/v1.0/groups using the new MSGraphClient. I've granted the permission scope Group.ReadWrite.All for Microsoft Graph.

@s-KaiNet

This comment has been minimized.

Show comment
Hide comment
@s-KaiNet

s-KaiNet Sep 11, 2018

Contributor

@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 Group.ReadWrite.All permission, which should be admin consented?

Contributor

s-KaiNet commented Sep 11, 2018

@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 Group.ReadWrite.All permission, which should be admin consented?

@olemp

This comment has been minimized.

Show comment
Hide comment
@olemp

olemp Sep 11, 2018

@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).

olemp commented Sep 11, 2018

@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).

@DnsSrinath

This comment has been minimized.

Show comment
Hide comment
@DnsSrinath

DnsSrinath Sep 12, 2018

Any idea why "SharePoint Online Client Extensibility web application Principle" not available in my tenant?

image

Is there a way to enable "SharePoint Online Client Extensibility web application Principle" in a tenant?

image

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.

DnsSrinath commented Sep 12, 2018

Any idea why "SharePoint Online Client Extensibility web application Principle" not available in my tenant?

image

Is there a way to enable "SharePoint Online Client Extensibility web application Principle" in a tenant?

image

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.

@2toLeadMike 2toLeadMike referenced this issue Sep 13, 2018

Closed

SPFx 1.6 MSGraphClient consent doesn't work #2475

2 of 4 tasks complete
@VesaJuvonen

This comment has been minimized.

Show comment
Hide comment
@VesaJuvonen

VesaJuvonen Sep 13, 2018

Contributor

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.

Contributor

VesaJuvonen commented Sep 13, 2018

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.

@mwiedemeyer

This comment has been minimized.

Show comment
Hide comment
@mwiedemeyer

mwiedemeyer Oct 12, 2018

I just want to add, that I had the same issues and the solution was quiet simple:
The "resource" in webApiPermissionRequests element allows only names, not IDs.
In our tenant we had 2 different apps in "Enterprise Apps" with the same name and the API Permissions in the new SharePoint Admin Center added the wrong app to the permissions.
Solution: Delete the "wrong" app and re-approve the API permissions.

mwiedemeyer commented Oct 12, 2018

I just want to add, that I had the same issues and the solution was quiet simple:
The "resource" in webApiPermissionRequests element allows only names, not IDs.
In our tenant we had 2 different apps in "Enterprise Apps" with the same name and the API Permissions in the new SharePoint Admin Center added the wrong app to the permissions.
Solution: Delete the "wrong" app and re-approve the API permissions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment