Permissions for PnP.PowerShell seem excessive

[cimares]

I tried switching to the new PnP.PowerShell for a simple task that up until now I've been doing using the old PNPPowerShell modules which have worked fine. Using Export-PnPListToProvisioningTemplate works just fine as a Site Collection admin and allows me to extract a list happily, Importing that into a new Site Collection again works fine.

When I switch to PnP.PowerShell and use Export-PnPListToSiteDesign instead the script gets a fair way through the extraction, but then fails with:

Export-PnPListToSiteTemplate : {"odata.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."}}}

I'm assuming that even though I'm connecting with -UseWebLogin, this doesn't provide enough permissions and instead I need to register the App for PnP PowerShell and use -Interactive. Unfortunately for this client, that level of access is not going to be available and SC Admin is the maximum I can be granted.

What are the options for this level of access going forward with PnP?

Updated with the Answer:
Connect-PnPOnline -Url [url] -Interactive -LaunchBrowser
This gives User context level access, without the App registration (or at least it appeared to.. now it's not working)

[ToddKlindt]

Can you have one of the client's SharePoint or Global admin register the app? If they do they can give your user access to it and then you can get in. The App's permissions are delegated, so the user using the PnP.PowerShell still needs permissions to whatever they're accessing. The App Registration doesn't give them an end run around that.
Starting in stable build 1.3.0 Connect-PnPOnline has a parameter, -Interactive, that replaces -UseWebLogin. I don't completely have my head around the differences between the two, so I can't promise it will work. It's quick to try though.
You can also have both the SharePointPnPPowerShellOnline and PnP.PowerShell modules installed on your system at the same time. That way you can use SharePointPnPPowerShellOnline while you're trying to sort the App Reg issues out with this client, but use PnP.PowerShell wherever else it works. If you have both installed make sure you use Import-Module to bring the correct one for your script or session.

[cimares]

Cheers Todd, I think the big problem is perception here. We've been using PnP PowerShell (legacy) for so long with this client that we've not needed to go through the pain of an App Registration with them (and it is a huge pain!), especially for what seems such a long and wide ranging list of permissions.

I must admit I didn't consider delegated permissions and assumed that there was a bunch of App-Only permissions in there too. I'll have to show the InfoSec guys exactly what it sets up in a demo tenant and see if I can get sign-off from them.

For some of our larger clients this becomes quite an initial overhead when you're used to just rocking up with some simple PowerShell scripts to update stuff in a Site Collection that you have full SC admin access to.

[ToddKlindt]

Hey Paul! :)
You're totally right about the perception. It's tough to sell the additional steps when they they weren't necessary before. And the list of permissions is scary, I agree.
I appreciate you bringing it up here and having the discussion. You're not the only person running up against these hurdles. Hearing about the different perspectives is helpful in finding solutions. In some of these cases sticking with the legacy module for a while might be your best solution.

[cimares]

Thanks Todd,

We were having a separate discussion on this subject on Facebook, and Paolo Pialorsi pointed me in the direction of the following command structure:

Connect-PnPOnline -Url [url] -Interactive -LaunchBrowser

This approach allows me to connect directly to the site collection and work in the existing User Context, without the need for an App Registration. This makes a massive difference and helps save that painful InfoSec and Change control in the current client environment!

[ToddKlindt]

I was following on Facebook. I didn't have anything to add so I hadn't responded. Have you tried -Interactive with or without -LaunchBrowser? I tried them both and they both required me to consent with an admin account. When I didn't they both errored out. If I understand your scenario correctly they won't work for you.

[javenu]

Sticking with the legacy module as recommended is problematic as I am trying to package and deliver a solution for a client that performs ongoing admin and sync using PnP. Would prefer to deliver that on the current PnP platform as legacy cmdlets could start to fail over time - this is a risk. The InfoSec and perm hurdles required to run scripts reduces the value prop of PnP Powershell - namely the promise of simple SPO management in the enterprise. At this point, it's become a specialized toolset mainly for tenant admins, not Site Collection admins - who arguably would benefit the most from the day to day site management facilitation.

[cimares]

Without the -launchbrowser it popped up the admin consent, with it I went straight in and connected to the site collection. I was then able to run the export list to site template command. <edit> this doesn't appear to be the case now.. so unsure how it worked previously.. Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Todd Klindt <[email protected]> Sent: Sunday, February 14, 2021 4:23:04 AM To: pnp/powershell <[email protected]> Cc: Paul Hunt (@cimares) <[email protected]>; Author <[email protected]> Subject: Re: [pnp/powershell] Permissions for PnP.PowerShell seem excessive (#269) I was following on Facebook. I didn't have anything to add so I hadn't responded. Have you tried -Interactive with or without -LaunchBrowser? I tried them both and they both required me to consent with an admin account. When I didn't they both errored out. If I understand your scenario correctly they won't work for you. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#269 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABYU43HFJ3YDP4KK6PTE23LS65F2RANCNFSM4XRCFBIQ>.

[bernhardk4t]

This is related... With build 1.3.0 I get this error (using -UseWebLogin):

Get-PnPSiteTemplate : {"odata.error":{"code":"-2147024891, System.UnauthorizedAccessException","message":{"lang":"de-DE","value":"Zugriff verweigert. Sie haben keine Berechtigung, diesen Vorgang auszuf\u00fchren oder auf diese Ressource zuzugreifen."}}}

(which means "Access Denied etc."). It happens after some time when the process is already running. It is related to something with members/groups though, as it was pointed out in another post.

It worked with 1.2.0, and same here -Interactive is not really an option for our customer projects - this means tons of discussions about safety ... :-)

I did try the

Connect-PnPOnline -Url [url] -Interactive -LaunchBrowser

but I still can't get ahead (at the customer site I'm SharePoint Admin but not Global Admin - which used to be enough with the older versions)

So no problem - I can help myself with the older versions, but maybe you can find out what causes the error accessing a language resource. And also if there's a less demanding -interactive switch.

Cheers, Bernhard

[javenu]

I would like to use 1.3.0 but am unable to run the commands I need to provision a site as a Site Collection Admin using -UseWebLogin

For instance, I can't connect to a page using Get-PnPClientSitePage
Get-PnPClientSidePage : {"odata.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."}}}:

Can't add a Web Part
Add-PnPClientSideWebPart : {"odata.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."}}}

The new PnP PowerShell is only usable by tenant admins, which in a large enterprise are going to be a select few.
This new version is useless for the Site Collection admins who do much of the day-to-day site admin and management.

[ToddKlindt]

The new PnP PowerShell is only usable by tenant admins, which in a large enterprise are going to be a select few.
This new version is useless for the Site Collection admins who do much of the day-to-day site admin and management.

Site Collection admins can use the new PnP.PowerShell. A tenant admin has to register the Azure Application, but after that is done a site collection admin can use it against site collections in that tenant that they have permissions to.

[ZoeCunningham-Defra]

So I'm trying to get this app approved in my company. I completely understand the delegated permissions and users will only be allowed to do what their user account permissions grant them, but we have another question:
Can we control exactly which users are allowed to use this app? We'd like to ring fence it so only specified users can use the app once registered.
Appreciate any info on if this is possible, and if so, how to do it. Thanks.