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

[thuld]

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 '[email protected] ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + 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 '[email protected]' -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?

• [x] Windows
• [ ] Linux
• [ ] MacOS
• [ ] Azure Cloud Shell
• [ ] Azure Functions
• [ ] Other : please specify

[BaronSparky]

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]

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]

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:

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

[BaronSparky]

The same for me also...

[erwinvanhunen]

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]]

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]

@erwinvanhunen Is there any progress on this?

[SebasT87]

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

[barkerboy8]

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

[Markarend]

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]

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

[SebasT87]

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

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

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

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]

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]

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

[ToddKlindt]

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]

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

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]]

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]

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]

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]

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]

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]

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]

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]

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]

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

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.