[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 '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?

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

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]

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

[mikelee1313]

Anyone updates for the new year?

[Yvand]

Today I got an update from Engineering: They continued the work and made progress since my last message, but they still don't have a more precise timeline to communicate, very unfortunately

[heinrich-ulbricht]

Imagine being a PM and getting this response from engineering ⛈️😉

[Yvand]

@heinrich-ulbricht I'm just the messenger who understands the frustration of people in this thread who are waiting for this fix for so long.
I take the time to chase Engineering and provide whatever update I have, even if it is a poor one.
I could have chosen to just remain silent

[Mntz]

Is the current work-around still working?

I created a new Azure AD App + secret.
Next on the tenant-admin.sharepoint.com/_layouts/15/appinv.aspx added the FullControl rights to both the content and social scope.
Using Connect-PnPOnline with ClientId and ClientSecret, the Get-PnPUserProfileProperty command is working fine.
But Set-PnPUserProfileProperty returns the following error:

Set-PnPUserProfileProperty : De huidige gebruiker is niet gemachtigd om deze bewerking uit te voeren.
At line:1 char:1
+ Set-PnPUserProfileProperty -Account $acc.AccountName -PropertyName 'S ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Set-PnPUserProfileProperty], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,PnP.PowerShell.Commands.UserProfiles.SetUserProfileProperty

The error text in this Dutch tenant translates the same but the CategoryInfo differs from the topic start.

[brianpmccullough]

Is the current work-around still working?

I created a new Azure AD App + secret. Next on the tenant-admin.sharepoint.com/_layouts/15/appinv.aspx added the FullControl rights to both the content and social scope. Using Connect-PnPOnline with ClientId and ClientSecret, the Get-PnPUserProfileProperty command is working fine. But Set-PnPUserProfileProperty returns the following error:

Set-PnPUserProfileProperty : De huidige gebruiker is niet gemachtigd om deze bewerking uit te voeren.
At line:1 char:1
+ Set-PnPUserProfileProperty -Account $acc.AccountName -PropertyName 'S ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Set-PnPUserProfileProperty], PSInvalidOperationException
    + FullyQualifiedErrorId : InvalidOperation,PnP.PowerShell.Commands.UserProfiles.SetUserProfileProperty

The error text in this Dutch tenant translates the same but the CategoryInfo differs from the topic start.

Did you run the following on each Geo where you need to perform the Get/Set? Also, if multi-geo, you will need to so the ACS registration (AppInv.aspx) on each central admin site.

set-spotenant -DisableCustomAppAuthentication $false

https://learn.microsoft.com/en-us/sharepoint/dev/solution-guidance/security-apponly-azureacs

[Mntz]

Found the issue... the error was kind of misleading:
I tried to set SPS-Location but the location value was not yet available in the term store.
Since I first tried Set-PnPUserProfileProperty using certificate authentication instead of using secrets I figured it was still the same issue, but no.

[brianpmccullough]

Yes, for sync scenarios, I usually let those termsets remain open - following the model that OOB SharePoint uses for fields like Job Title, etc.

[sli701]

ERROR: This operation requires you to be managing your own data or have administrator privileges.

Getting the same error here when using Azure Function and App Registration.

Is there a fix?

[RichWorld-Tech]

Connect-PnPOnline -Url $URL -UseWebLogin. This is not ideal nor what we want for automation purposes, but it will work. When working on multiple users, I add it to the Begin block and do the work in the Process block of the script in order to pipe information to the script. Hope that helps.

[Milkias1]

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!

Thank you, Markarend this worked for me.

[jackpoz]

Just wanted to mention that New-PnPUPABulkImportJob works fine with an app registration with Certificate and permissions assigned only in AAD with SharePoint "Sites.FullControl.All" and "User.ReadWrite.All" and no permissions assigned in SPO at /_layouts/15/appinv.aspx , tested it this week in 2 different tenants.

[testad]

Thanks a lot @jackpoz, will definitely try this out. Glad to get rid of this ACS dependance.

[rayghost503]

SPOM

This seems to be working for me. I just fixed an automation I had working.

[jackpoz]

I was able to test New-PnPUPABulkImportJob with Managed Identity in Automation Account in Azure and it works fine that way too

[KoenZomers]

Good to hear the feedback here that it has started to work for some of you. Just for awareness, the PG is still actively working on completing implementing this scenario. This means for now that it might already work for you, but specific scenarios, such as when you're using taxonomy driven user profile fields, might not work yet. Keep this in mind when switching to the Azure AD / Entra ID option. Test everything thoroughly. If it works for your use case, you're good to go, if it doesn't yet, bear a little longer with us, it's still work in progress.

[bpw320]

I got the error: the current user has insufficient permissions to perform this operation for:
SetMultiValuedProfileProperty
SetSingleValueProfileProperty for property: SPS-Location

However, SetSingleValueProfileProperty does work for other custom properties

I use PNP.framework, set ClientContext using new AuthenticationManager().GetACSAppOnlyContext(siteurl, clientid, secret)

Thanks

[sidndis27]

Get-PnPUserProfileProperty works with -ClientSecret but not working with -Thumbprint. Getting Access Denied. Can someone please help?

I used permissions

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

[WiljanD]

I fixed the issue with the latest PowerShell module on Powershell 7.2 with the command "Sync-PnPSharePointUserProfilesFromAzureActiveDirectory" all information is well documented: https://pnp.github.io/powershell/cmdlets/Sync-PnPSharePointUserProfilesFromAzureActiveDirectory.html

The service principal needs to have the following rights:
Graph API:
[User.Read.All]

Sharepoint API
[User.Read.All]
[Sites.FullControl.All]

Which will look like:

The module also has commands for granting these rights in an easy way:
Add-PnPAzureADServicePrincipalAppRole -Principal "<Service Principal Name>" -AppRole "User.Read.All" -BuiltInType MicrosoftGraph
Add-PnPAzureADServicePrincipalAppRole -Principal "<Service Principal Name>" -AppRole "Sites.FullControl.All" -BuiltInType SharePointOnline
Add-PnPAzureADServicePrincipalAppRole -Principal "<Service Principal Name>" -AppRole "User.Read.All" -BuiltInType SharePointOnline

Then also grant the permissions in Sharepoint:
App permission:
<AppPermissionRequests AllowAppOnlyPolicy="true"> <AppPermissionRequest Scope="http://sharepoint/content/tenant" Right="FullControl" /> </AppPermissionRequests>
I suspect that this rights package will help in granting rights also for Set-PnPUserProfileProperty, but I started using the latest module because it adds support for using System managed identities and User Managed Identities which I'm using in combination with a automation account to sync the attributes from Azure AD to SharePoint.

The script looks like this:

Connect-PnPOnline tentantname-admin.sharepoint.com -ManagedIdentity -UserAssignedManagedIdentityClientId "Service principal ObjectID"

$users = Get-PnPAzureADUser -select "OnPremisesSamAccountName"

Sync-PnPSharePointUserProfilesFromAzureActiveDirectory -UserProfilePropertyMapping @{"UserName"="OnPremisesSamAccountName";"CellPhone"="MobilePhone"} -Users $users -Folder "Documents"

Disconnect-PnPOnline

[ttd-kevinclement]

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

Is there a way to assign these permissions using the PnP commandlets? Or some non SharePoint registration?
Working with a ManagedIdentity for Runbooks, most of the PnP commands seem to work minus the PnPUserProfileProperty and I'm assuming others as well.

Current permissions associated with the managed identity, as well as granted said identity sharepoint administrator role (Which doesn't seem to do much)

[AndersRask]

In my testing the issue with ACL is now solved, and so legacy auth using appreg.aspx is no longer needed.
I have tested using both system managed identity and app reg with cert. Both works fine updating user profile properties including term set fields with only API permissions

Set-PnPUserProfileProperty -Account adelev@contoso.onmicrosoft.com -PropertyName "SPS-Location" -Value "Stockholm"

The key is adding TermStore.ReadWrite.All. You can ignore the exchange perm as it was only used for testing

[ttd-kevinclement]

In my testing the issue with ACL is now solved, and so legacy auth using appreg.aspx is no longer needed. I have tested using both system managed identity and app reg with cert. Both works fine updating user profile properties including term set fields with only API permissions

Set-PnPUserProfileProperty -Account adelev@contoso.onmicrosoft.com -PropertyName "SPS-Location" -Value "Stockholm"

The key is adding TermStore.ReadWrite.All. You can ignore the exchange perm as it was only used for testing

Looks like TermStore permission is all that was missing. Rest of the commands seem to work now.

[KoenZomers]

Thanks @AndersRask for sharing and @ttd-kevinclement for confirming. I will update our documentation with this great info.

I guess with that, we can also finally close this long running open issue. Thanks for providing all the feedback and thoughts here everyone.