Set up Enterprise App to use App-Only Sites.Selected permissions and wite to SharePoint with PnP Powershell

By -

I wanted to run unattended scripts against SharePoint for various governance and content cleanup jobs and found the guidance for this to be a little confusing.   I think it's a good idea to limit the access of any script, so I prefer to set up an App per script and use the Sites.Selected permission to limit the sites to which my app has access.   Here's the process I used to get it to work:

You can register an app in the Azure portal UI, but there's a few steps that must be performed with PowerShell, so I figured just doing it all in Powershell made it consistent.  

Step 0:  Get the right version of PnP.Powershell

I also had to use the PnP.PowerShell 2.2.81 nightly build because there was a bug introduced in 2.2.0.  If you need to get a specific version you can run Install-Module, but I prefer to use Save-Module with specific version so I can keep different version of PnP.PowerShell around to avoid having my old scripts affected by new modules and potential regression issues.  

Once you have the right version, run the following line (or include in your script file):

Import-Module D:\psbin\PnP.PowerShell\2.2.81\PnP.PowerShell.psd1

Step 1: Register the App

In this step we'll do the one time app registration with a certificate, then we'll give the App Sites.Selected WRITE permission (your only choice when doing the initial grant is READ|WRITE).  Immediately after, we update the permissions with FullControl, as this is required to upload files.

Permissions Needed: Global Administrator/Azure AD Admin

In my Dev tenant this is no problem since I have this right.  In prod environments I don't typically have this right so I would plan to hand this script or the steps off to one of my admins.

Generate Certificate

You'll need to use a certificate to authenticate with your app.  In this example I am testing against my developer tenant.  I'm using a self-signed cert, but you can be more secure and use one created by a trusted CA.   If you go the trusted CA route, you can skip to the registration

$pw = "USEAGOODPASSWORD" #this is not a good password....

$commonName = 'EAUpload'

$certificateName = "EASharePointSiteUpload_TEST"

$certFile = "$certificateName.cer"

$certPfx = "$certificateName.pfx"

$certPass = (ConvertTo-SecureString -String $pw -AsPlainText -Force)

New-PnPAzureCertificate -CommonName $commonName -OutPfx "$certPfx" -OutCert "$certFile" -CertificatePassword $certPass

Register the App with a Certificate

Make sure to update the script to replace YOURTENANT then run

# SETUP

$hostUrl = "https://YOURTENANT.sharepoint.com"

$hostRelativeUrl = "/sites/EAUploadTest" #change to whatever site you want the app to work with

$siteUrl = "$hostUrl$hostRelativeUrl"

$appName = "EAUploadTestApp_TEST"

$tenant = "YOURTENANT.onmicrosoft.com"

# END SETUP

Write-Host "Registering App on $siteUrl"

Connect-PnPOnline $siteUrl -Interactive

$reg = Register-PnPAzureADApp -ApplicationName $appName `

                        -Tenant $tenant `

                        -CertificatePath $certPfx `

                        -CertificatePassword $certPass `

                        -GraphApplicationPermissions "User.Read.All" `

                        -SharePointApplicationPermissions  "Sites.Selected" `

                        -Interactive

Write-Host "Granting WRITE permissions to app on: $siteUrl"

$grant = Grant-PnPAzureADAppSitePermission -Permissions Write -Site $siteUrl -AppId "PUTAPPIDHERE" -DisplayName "MYAPP_SITESSELECTED_FULL"

$reset = Set-PnPAzureADAppSitePermission -PermissionId $grant.Id -Permissions FullControl

Disconnect-PnPOnline

Step 2:  Allow NoScript on the SP Site

I couldn't figure out any way around this, seems that a site has to have NoScript disabled in order to allow api uploads.

Permissions Needed:   SP Admin

Connect-PnPOnline $siteUrl -Interactive

Write-Host "Setting NoScript to FALSE (so we can do file uploads)"

Set-PnPSite -NoScriptSite $false

Write-Host "Disconnecting from Admin (User) Credentials"

Disconnect-PnPOnline


Step 3: Test with App-Only Credentials

Here we connect with only App credentials (not user credentials).

Write-Host "Connecting with App Credentials"

Connect-PnPOnline -Url $siteUrl -ClientId $reg.'AzureAppId/ClientId' -Tenant $tenant -CertificatePath $certPfx -CertificatePassword $certPass #-ThumbPrint $reg.'Certificate Thumbprint' 

Write-Host "--Saving File"

$testFile = 'testFile.txt' 

Add-PnPFile -Path $testFile -Folder "$hostRelativeUrl/Shared Documents/"

Write-Host "--Disconnecting from App Credentials"

Disconnect-PnPOnline

Comments

Post a Comment

Popular posts from this blog

Programmatically Update Page Layouts

By -
I updated my page layouts that I deployed as a feature, but found that I could not overwrite the Layout File. The solution was to add a new page layout and then you would have to associate the new layout with every page on your site that used it. Obviously with a site of any size you'd have a lot of manual work to get this done, so doing it programmatically makes for a much better (and thorough) approach. After you've got your new page layouts, you could do something like this (in your event receiver class): public override void FeatureActivated(SPFeatureReceiverProperties properties) { //replace current page layouts with new page layouts on all pages SPWeb web = SPContext.Current.Web; SwapPageLayout(web, "FullWidthContentWithTitleV1.aspx", "FullWidthContentWithTitleV2.aspx"); } private void SwapPageLayout(SPWeb web, string oldPageLayoutName, string newPageLayoutName) { PublishingWeb pubWeb = PublishingWeb.GetPu...
Read more

Microsoft Virtualilzation Headaches

By -
As a SharePoint consultant, I am constantly moving from client to client and the best way to develop and test the code, designs and configurations for each client while maintaining complete separation is to virtualize. Since I work for a Microsoft partner, we try to use Microsoft tools and technologies as much as possible, which can be quite frustrating, as you will find out below. I recently started working for a large client with a global presence whose IT policies are well-established, difficult to change and not always up-to-date. In that vein, enter the corporate VPN: it's a web-based signin with a host checker that doesn't support any x64 OS. This prompted me, running Win 7 x64, to try to get a co-worker's Hyper-V Win2k3 x86 MOSS VM and run it in Windows Virtual PC . Seems like a logical thing to do, right? I mean, a Microsoft VHD should work, and be able to be imported by other Microsoft tools, right? Wrong. After spending quite a bit of time trying to attach the VHD...
Read more

ERROR: Failed to create feature receiver...

By -
I was working on a STSDev project which deployed a feature with a feature receiver. I had the feature working without the FeatureReceiver but as soon as I added the FeatureReceiver related attributes to my <Feature> element I got the following error: Failed to create feature receiver object from assembly "Org.Project.Solution, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c632353d405b3209", type "Org.Project.Solution.MyFeature.FeatureReceiver" for feature 6a9b2358-ea4e-486d-a4e4-4f813c52ce88: System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, Boolean nonPublic) at System.Activator.CreateInstance(Type type) at Microsoft.SharePoint.Administration.SPFeatureDefinition.get_ReceiverObject() After much digging around I discovered that STSDEV's Solution config file refers to a namespace as well as the dll. My FeatureReceiver's namespace was not prefixed with the right namespace So just...
Read more