SharePoint PnP logo

How to fix Add-PnPApp failing with an Access Denied error

This post was most recently updated on December 31st, 2018.

This was a peculiar case! An issue I hadn’t run into before, and luckily a disturbingly simple fix. But first, let’s set up the scene.

We were running a long-ish PowerShell script using a Global Administrator account. One part of the script was supposed to add and deploy a couple of SharePoint apps. But while running Add-PnPApp, we ran into errors:

Add-PnPApp -Path $path -Scope $app.Scope -ErrorAc… , Error: {"error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"en-US","value":"Access denied. You do not have permission to perform this action or access this resource."}}}

Oh. That’s… A bit surprising for a Global Administrator, right? What’s causing this?

Security. It’s always security…

This particular customer was fairly strict about their security. This had caused them to remove a lot of the built-in security principals from a lot of places – any created SharePoint sites included. This is not necessarily a bad thing, but security hardening might break things if you don’t know what you’re doing.

In this particular case, the security hardening was also applied to the app catalog site of the SharePoint tenant. This means that their built-in principals like “SharePoint Service Administrator” and “Company Administrator” were removed. Actually, everyone but their one service account (which wasn’t the Global Administrator account we were using here), were removed.

Consequently, SharePoint and Global Administrators lost admin permissions on the site, although they still retained access there (it’s kind of difficult to completely block a Global Administrator from a site, after all).

Probably needless to say, this configuration blocks even Global Administrators from adding or installing new apps using the PnP commandlets – like Add-PnPApp – or even using the GUI.

Solution: Don’t mess with the built-in principals!

A lot of authentication issues in SharePoint are caused by someone messing with the built-in credentials.

In case you run into this issue, make it the first thing you do to verify, that the following built-in principals are in place. So if you already have messed with them, add them back!

The following principals are required for the App Catalog site to make Add-PnPApp to work:

  • Company Administrator
    • Maps to Global Administrators
  • SharePoint Service Administrators
    • Maps to, well, SharePoint Service Administrators

Whichever account you’re using to run Add-PnPApp needs to be an admin/owner on the App Catalog site.

How to fix this?

Browse to your SharePoint Administration, select Site Collections (or Sites) and find your App Catalog from the list. Select it, and select “Owners > Manage Administrators”. The screenshot below shows what the configuration should look like.

SharePoint Online App Catalog Administrators
SharePoint Online App Catalog Administrators

Since this event, I’ve paid more attention to App Catalog permissions, and I’ve seen them deviate from the configuration above on some other tenants, too. Perhaps there’s something interesting also happening in the initial provisioning of the App Catalog, and at least sometimes the built-in principals are shut out of the created site by accident? This functionality doesn’t seem like it would make much sense – but maybe it’s an unintended implementation by Microsoft.

Be that as it may, adding the built-in service principals Company Administrator and SharePoint Service Administrator to the administrators of the app catalog site should fix the commandlets for you.

The following two tabs change content below.
mm

Antti K. Koskela

Solutions Architect / Escalations Engineer at Koskila / Norppandalotti Software / Valo Solutions
Antti Koskela is a proud digital native nomadic millenial full stack developer (is that enough funny buzzwords? That's definitely enough funny buzzwords!), who works as a Solutions Architect for Valo Intranet, the product that will make you fall in love with your intranet. Working with the global partner network, he's responsible for the success of Valo deployments happening all around the world. He's been a developer from 2004 (starting with PHP and Java), and he's been bending and twisting SharePoint into different shapes since MOSS. Nowadays he's not only working on SharePoint, but also on .NET projects, Azure, Office 365 and a lot of other stuff. This is his personal professional (e.g. professional, but definitely personal) blog.

Leave a Reply

Your email address will not be published. Required fields are marked *