[BUG] Add-PnPApp Fails with access denied when connected using a global tenant administrator account (on Windows)

[reidav]

Reporting an Issue

Add-PnPApp fails with access denied when connected using a tenant global administrator account.

• Tested using sharepoint admin and tenant app catalog url (Connect-PnPOnline).
• Tenant global administrator is also a site collection administrator of the app catalog site (built-in principals are also available Company Administrator and SharePoint Service Administrators)
• Also tested using a new app catalog site (deleted the old one and recreated it)
• MFA is not enabled on the admin account
• Get-PnPApp is still working
• It's also working with the latest version of "SharePointPnPPowerShellOnline" cmdlets

Expected behavior

App should be uploaded into the tenant site app catalog

Actual behavior

Steps to reproduce behavior

Connect-PnPOnline -Url 'siteUrl' -Credentials 'credentials' Add-PnPApp -Path 'appPath'

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

0.3.7 (Nightly) + Pswh 7.1.0

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

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

[reidav]

I'm still trying to investigate on it, if you have a quick tip to monitor outgoing traffic using dotnet core on windows.. I'm still not able to track the request, even using Fiddler everywhere or Fiddler classic as mentioned by @veronicageek. It works only with legacy PnP PowerShell for now. I'll test using Linux also.

[reidav]

Just tried on archlinux, using 0.3.7 (Nightly) + Pswh 7.1.0, same tenant, same user, it works, app package is uploaded.

[reidav]

This issue is related to pnpframework, my apologies for tracking it here ;

• AppManager.cs, there is a method called "Task BaseAddRequest****(byte[] file, string filename, bool overwrite, int timeoutSeconds, AppCatalogScope scope)"

• Only for Windows Platform, we're trying to get the requestDigest which fails with access denied var requestDigest = await httpClient.GetRequestDigestWithCookieAuthAsync(handler.CookieContainer, _context.Url);

• Not sure to get why we're doing it only for Windows, commenting the line resolves the issue in my case.

@erwinvanhunen May I kindly ask you to transfer it to pnpframework repos please ? Thx

[erwinvanhunen]

@reidav regarding monitoring on Windows: I use Fiddler. I found out that the order of Launching is important. Launch Fiddler first, then launch PowerShell core. It's important to do it in that order.

[erwinvanhunen]

There is indeed a logic issue with retrieving the request digest retrieval. I will move this issue to the PnP Framework repo and take it from there. I already am working on a fix.

[reidav]

@reidav regarding monitoring on Windows: I use Fiddler. I found out that the order of Launching is important. Launch Fiddler first, then launch PowerShell core. It's important to do it in that order.

You made my day ! I've been through lots of details to get a trace ($env:http_proxy, wireshark sslkeylog and many more ..) Respecting the start order is really a key for success :) Thanks !

[erwinvanhunen]

We just merged a fix for this issue which will be available in the nightly release of tomorrow in both the PnP Framework and PnP PowerShell.