pnp / powershell

PnP PowerShell
https://pnp.github.io/powershell
MIT License
673 stars 344 forks source link

[BUG] Set-PnPUserProfileProperty : Access denied. You do not have permission to perform #277

Closed thuld closed 3 months ago

thuld commented 3 years ago

Please see also related discussion Can Get nut can't Set with pnp.powershell

Expected behavior

Cmdlet Set-PnPUserProfileProperty allows to update of user-profile properties

Actual behavior

Error is raised:

Set-PnPUserProfileProperty : Access denied. You do not have permission to perform this action or access this resource.
At line:1 char:1
+ Set-PnPUserProfileProperty -Account 'test@foobar.com ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : WriteError: (:) [Set-PnPUserProfileProperty], ServerUnauthorizedAccessException
    + FullyQualifiedErrorId : EXCEPTION,PnP.PowerShell.Commands.UserProfiles.SetUserProfileProperty

Steps to reproduce behavior

  1. Connect SharePoint Online
  2. Run following code: Set-PnPUserProfileProperty -Account 'test@foobar.com' -PropertyName 'WorkPhone' -Value '0123456789'

What is the version of the Cmdlet module you are running?

Manifest 1.3.0 PnP.PowerShell {Add-PnPAlert, Add-PnPApp, Add-PnPApplicationCustomizer, Add-PnPContentType...}

Which operating system/environment are you running PnP PowerShell on?

BaronSparky commented 3 years ago

How did you connect to SPO? i.e. which switch on the "Connect-PnPOnline"?

I have noticed a similar issue this morning, i.e. "Access denied." when using the "-UseWebLogin" or "-Interactive" arguments. However, when I connected via "-Credentials" on the "Connect-PnPOnline", it worked.

Perhaps the issue is with the Connect-PnPOnline cmdlet.

erwinvanhunen commented 3 years ago

The issue is most likely connected to the registration of the PnP Management Shell application that is in place in your Azure AD. Run Register-PnPManagementShellApplication again, it will change the granted permissions: we added the userprofile readwrite right there like 2 weeks ago (it used to be only read access).

thuld commented 3 years ago

I am using the following approach to connect to SharePoint Online:

Connect-PnPOnline -Url 'https://foobar4com-admin.sharepoint.com' -Interactive

@erwinvanhunen We registered the application yesterday and the permissions of this application seems ok:

image

Update: I have now executed Register-PnPManagementShellAccess and then created a new connection, but the error is the same.

BaronSparky commented 3 years ago

The same for me also...

erwinvanhunen commented 3 years ago

I just tested and indeed it doesn't work with a bearer token (which is what we use by default). It seems that that is not (more?) supported. We'll investigate that. I noticed that if you use -UseWebLogin (which is cookie based auth) it does work.

I'll leave this issue open while we investigate.

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days

Geo-Ron commented 3 years ago

@erwinvanhunen Is there any progress on this?

SebasT87 commented 3 years ago

Same problem here, hoping for a quick fix. As a workaround i did a rollback to the former SharepointPnP.

barkerboy8 commented 3 years ago

I'm having the same issue - when will this be fixed?

Markarend commented 3 years ago

Here are a couple of possible clues, though I still get the same error behavior discussed in this issue.

Accessing SharePoint using an application context, also known as app-only says "User Profile CSOM write operations do not work with Azure AD application - read operations work. Both read and write operations work through SharePoint App-Only principal". Then Granting access using SharePoint App-Only gives instructions for setting that up. I was feeling pretty good when I found this, but then when I tested, still "Access denied. You do not have permission to perform this action or access this resource. Microsoft.SharePoint.Client.ServerUnauthorizedAccessException, ServerErrorCode : -2147024891, ServerErrorTypeName : System.UnauthorizedAccessException".

Another possible clue is that Granting access using SharePoint App-Only shows -AppId and -AppSecret parameters for Connect-PnPOnline, but the current version (1.3.0?) doesn't provide those parameters, only -ClientId and -ClientSecret.

Is there a PnP core version I can test with that provides -AppId and -AppSecret?

Markarend commented 3 years ago

@SebasT87 what version of SharePointPnP are you using as a workaround?

SebasT87 commented 3 years ago

@SebasT87 what version of SharePointPnP are you using as a workaround?

That would be SharePointPnPPowerShellOnline to be exact. Which can be installed using: Install-Module SharePointPnPPowerShellOnline

veronicageek commented 3 years ago

@Markarend

My customer needs a fix for this!

I'd like to remind you that this repo is community driven, from people contributing on their own personal time. So please be patient as we may also have unforeseen priorities.

Markarend commented 3 years ago

@veronicageek, my apologies for seeming demanding, the exclamation point is a bit overused these days! I absolutely appreciate everyone's supporting each other, and I'll post something if I find an answer. I'm trying some things in this article now: https://dev.to/svarukala/introducing-the-new-pnp-powershell-based-on-net-core-3-1-and-learn-how-it-s-authentication-works-pn7.

Markarend commented 3 years ago

Can anyone share what Connect-PnPOnline parameter set and values to use to authenticate from an Azure Function App so the script can write User Profile properties without requiring an interactive login?

I used Register-PnPManagementShellAccess successfully and it appears to be configured correctly. But I'm unsure how to tell Connect-PnPOnline to use the PnP Management Shell app that it installs, except with -Interactive which only works locally, not from an Azure Function App.

Also tried these approaches to no avail. All can read SP profile properties but none can write: Connect-PnPOnline docs Example 6 (why doesn't this work if the app has SharePoint | User.ReadWrite.All | Application | Read and write user profiles?)

Granting access using SharePoint App-Only (may be deprecated, but moot because it doesn't work though it says it should for this specific scenario)

Many thanks

Markarend commented 3 years ago

ONE SOLUTION

Finally found a way to authenticate to SharePoint online to write profile properties without an interactive/user logon, that works from Azure function app. Unfortunately it uses ACS which is retired now but explicitly still supported for SharePoint use. So it's not my preferred approach, but as it actually works, it's better than all other approaches so far.

The key is to follow this article Granting access using SharePoint App-Only, but to add the scope /sharepoint/social/tenant. Update the Permission Request XML as follows, and it will permit writing user profile properties.

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" />
  <AppPermissionRequest Scope="http://sharepoint/social/tenant" Right="FullControl" />
</AppPermissionRequests>

Still looking for a more "modern" approach that's not just supported as a waiver from a retired approach. Many thanks to all!

patrickTimmerman commented 3 years ago

Hello, Is there an ETA on this Bug when it will be resolved ?

ToddKlindt commented 3 years ago

Hello, Is there an ETA on this Bug when it will be resolved ?

Like @veronicageek said upthread, all of this work is done by volunteers in their spare time. There usually isn't an ETA and some bugs don't get fixed.

Geo-Ron commented 3 years ago

@Markarend

My customer needs a fix for this!

I'd like to remind you that this repo is community driven, from people contributing on their own personal time. So please be patient as we may also have unforeseen priorities.

This is something I was unaware of.

erwinvanhunen commented 3 years ago

To give you an update: this is not an issue with PnP PowerShell but has to do with how SharePoint Online handles authorization. We provided Microsoft with this feedback and are waiting for them to reply on it. We have no ETA when that will happen.

github-actions[bot] commented 3 years ago

This issue is stale because it has been open 14 days with no activity. Remove stale label or comment or this will be closed in 5 days

bernardw1 commented 3 years ago

Hello All, I just wanted to comment saying that I am running into this issue still. Hopefully it is still on the radar to get fixed at some point.

Markarend commented 3 years ago

Hi Bernard, the PnP projects are "community driven" and AFAIK don't have a current timeline for fixing this. However please note there are many ways to connect with SharePoint online using PnP under different circumstances, and many of them do work. See the 13 different examples. May take some digging to get the most promising example for your scenario working. I needed to use Example 3 because of non-interactive login. First attempts didn't work just, but then I found more details about dependencies and finally got it working:

The key is to follow this article Granting access using SharePoint App-Only, but to add the scope /sharepoint/social/tenant. Update the Permission Request XML as follows, and it will permit writing user profile properties.

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" />
  <AppPermissionRequest Scope="http://sharepoint/social/tenant" Right="FullControl" />
</AppPermissionRequests>

This ACS which is retired now but explicitly still supported for SharePoint use

mirontoli commented 3 years ago

I just tested and indeed it doesn't work with a bearer token (which is what we use by default). It seems that that is not (more?) supported. We'll investigate that. I noticed that if you use -UseWebLogin (which is cookie based auth) it does work.

I'll leave this issue open while we investigate.

I tested it with -WebLogin and it indeed worked, thank you for that workaround. My environment is Windows, PnP.PowerShell 1.5.0.

wimp777 commented 3 years ago

This thread was closed? The bug is still active. With -interactive or using an Azure AD registered application with full control of sites and read/write of user profiles the error still exists.

gautamdsheth commented 3 years ago

Bot closed this issue due to inactivity, have opened it. The best option now would be to contact MS support and explain the case to them.

wimp777 commented 3 years ago

I have a suspicion that they will point back to this thread as its a community driven module and not maintained by Microsoft. I'll probably fall back to the old Sharepoint module and hope PnP gets updated as a work around.

gautamdsheth commented 3 years ago

You can do a minimal CSOM code and use the same access token for the support case. The underlying code is all CSOM C#. Unfortunately we have no clue if and when it will be fixed at all. Other cmdlets work perfectly fine with this auth flow but somehow this particular one doesn’t.

Markarend commented 3 years ago

@wimp777 and as mentioned above the workaround for Azure AD registered application is to use Granting access using SharePoint App-Only, which works if you also add the scope /sharepoint/social/tenant to those instructions. I know it's not the same as Azure AD registered but it's close and it works.

veronicageek commented 3 years ago

As @erwinvanhunen mentioned earlier in this thread, this isn't an issue with PowerShell PnP but dependant on MSFT's actions.

To give you an update: this is not an issue with PnP PowerShell but has to do with how SharePoint Online handles authorization. We provided Microsoft with this feedback and are waiting for them to reply on it. We have no ETA when that will happen.

EA12 commented 3 years ago

For me it is also working with -UseWebLogin

apinales commented 3 years ago

@veronicageek I opened a case with Microsoft and escalated this with their SharePoint Online engineers for this issue. I was told that this is not an issue on their end and that the issue is with the module itself.

erwinvanhunen commented 3 years ago

Unfortunately the SharePoint Online support engineers are not always 100% up to date about the limitations of their own products... :-( In this case the issue lies with the fact that a requested permission through an Azure AD application grant is not being recognized by SharePoint online specifically when it comes to the UPS (User Profile Service Application). With -UseWebLogin we use a different type of authentication (cookiebased/legacy) where as with all the other authentication methods we use the currently by Microsoft promoted way of authentication : Azure AD OAuth. We switched over to Azure AD OAuth as the default as more and more API requests we need to make are located in the Microsoft Graph. And the MS Graph only supports Azure AD OAuth.

In order for the OAuth authentication flow to work one needs to grant permissions to an Azure AD App registration, either a multi-tenant one alike the PnP Management Shell, or your own registered one. Our tests show that while the correct permissions are in place, SPO is not allowing the user to perform the actions. We brought this up with the product manager in charge of those APIs back then but are still awaiting feedback.

KoenZomers commented 3 years ago

@veronicageek I opened a case with Microsoft and escalated this with their SharePoint Online engineers for this issue. I was told that this is not an issue on their end and that the issue is with the module itself.

@apinales Please share your case number so I can look into this. Either here or send it to me privately.

apinales commented 3 years ago

25392520

KoenZomers commented 3 years ago

Thanks for sharing @apinales. Looking into it with the support team.

KoenZomers commented 3 years ago

@apinales Discussed this with the support team. We would very much like to dive into this issue but since your case has been closed two months ago already we would like to ask you to open a new case and have it reference your old case. If you can share the new case number with me, we'll ensure the correct details will be transferred to the engineer who will handle the case.

KoenZomers commented 3 years ago

Thanks for creating the ticket @apinales. I'm already aware of the ticket number, no need to share.

mohandivraniya commented 3 years ago

I am running into this issue right now. Some updates:

KoenZomers commented 3 years ago

@mohandivraniya can you share your case number so we can bundle it with the one we already have ongoing at the moment for this?

In my repro I'm getting the exact same error message as you. What stumbles me here is that you say it works with SharePointPnPPowerShellOnline. What version of it were you using? How did you connect using that?

mohandivraniya commented 3 years ago

My case number - 26234370 I am using SharePointPnPPowerShellOnline version 3.23.2007.0. I am connecting using Connect-PnPOnline -Url <> -UseWebLogin

KoenZomers commented 3 years ago

@mohandivraniya that explains it then. WebLogin will work as it works through a cookie to authenticate. The issue I believe we are all facing here is that we cannot register an application in AAD, apply the SharePoint Application principal Users.ReadWrite.All and use that to update a user profile. You would either need to assign the same client Id social permissions through AppInv.aspx as well to make it work or alternatively use -UseWebLogin.

Markarend commented 3 years ago

Here's a non-interactive method for connecting that does work to change user profile properties from a script running in an Azure runbook or function: Example 3 on this page. You must make one change. Follow this article Granting access using SharePoint App-Only, but add the scope /sharepoint/social/tenant. Update the Permission Request XML as follows, and it will permit writing user profile properties.

<AppPermissionRequests AllowAppOnlyPolicy="true">
  <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" />
  <AppPermissionRequest Scope="http://sharepoint/social/tenant" Right="FullControl" />
</AppPermissionRequests>

This ACS method is retired now but explicitly still supported for SharePoint use

KoenZomers commented 3 years ago

Thanks @Markarend for taking the time to detail out what I mentioned above to help others better understand the workaround. Still I believe that should be seen as a workaround. We're currently trying to see if filing a hotfix request for this has any chance of succeeding.

bcameron1231 commented 3 years ago

It would be awesome if Microsoft could fix this for Azure AD app-only contexts. This has been an issue for a while, and you lose a bit of transparency for your app registrations when you are building AD Apps, and subsequently have to register some permissions though appinv.aspx

heinrich-ulbricht commented 3 years ago

We are tripping over this as well. Found this thread and it's awesome that there are workarounds and - more important - this is being worked on. 👍

Standing in line and waiting for the engineers to click "ship it" ;)

KoenZomers commented 3 years ago

Turns out engineering already had a backlog item open to implement those permissions. The need to have this implemented is raised to engineering through a Critical Design Change Request (CDCR) now based on the discussion here with the aim of prioritizing the backlog item on upcoming sprints. They're currently looking into the efforts it would take to implement this.

KoenZomers commented 3 years ago

Just as an update, the topic is still on the table and has not been forgotten. No decision has been made yet if this functionality will be adjusted or not unfortunately.

asfd79 commented 3 years ago

Any update from Microsoft SharePoint Online on this issue?????

KoenZomers commented 3 years ago

Any update from Microsoft SharePoint Online on this issue?????

Its still under discussion. Vacation period makes things progress slow unfortunately. Also because there is an easy workaround available, it takes more effort to raise the priority on this.