Thumbnail Running applications with limited SharePoint permissions

Running applications with limited SharePoint permissions

Securing application access to SharePoint through Azure AD is easy. But often enough, these applications have far too much permissions. Do you really want to give an application access to your entire SharePoint tenant if it’s not necessary? This post is about how to let applications access SharePoint using the principle of least privilege.

God Mode: Sites.FullControl.All

Many companies employ them: solutions with standalone applications that execute a certain task. For example, automating the creation of SharePoint sites or enriching files with certain metadata. Many of these applications are configured to have permissions that are broader than what they actually need, for example Sites.FullControl.All.

sites-fullcontrol-all

This setup is reached through a few clicks of a mouse. After adding a certificate, this application can access the entire SharePoint tenant, which is convenient, but dangerous as well. It essentially has what I would call: ‘God mode’ on SharePoint. It’s just slightly short of being a ‘SharePoint Administrator’. This means that the keys to the kingdom are effectively handed over to the Developers who created the application. If they make a mistake, the entire SharePoint tenant might be impacted.

As long as you’re not provisioning entire sites, you don’t actually need this level of permissions. In those cases there is another way: tone down on the permissions using Resource Specific Consent (RSC). Resource Specific Consent means just what it sounds like: instead of assigning permissions to the entire tenant, you can assign permissions to specific resources. In the case of SharePoint these resources are sites. RSC is a step in the direction of more granular permission controls.

Step 1: Configure the Azure AD application registration

Configuring RSC starts with creating/updating an Azure AD application registration with the permission scope Sites.Selected.

sites-selected

As you can see RSC for SharePoint comes in two flavors: Microsoft Graph and SharePoint. The level of permissions that are granted is the same, the difference lies in what API the programmers are intending to use: The Microsoft Graph API or the SharePoint REST API.

RSC for Microsoft Teams: There's also RSC for Microsoft Teams, enabling access to resources like specific teams, channels or chats, but that's currently not configurable from Azure AD.

Step 2: Assign the application permissions to SharePoint sites

Important to note is that we’ve only registered the necessary scope for RSC in step 1. This was easy. However, there’s currently no place in the UI of Azure AD or SharePoint to configure what sites you want the application to have access to. This can be done by issuing requests against the Microsoft Graph API. For this post we’ll take another route though: assign the permissions using scripting.

Using the CLI for Microsoft 365 we can grant permissions in the following manner:


    m365 login

    m365 spo site apppermission add --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --permission fullcontrol --siteUrl "https://contoso.sharepoint.com/sites/project-x"
     

The above script needs to be run with appropriate administrative permissions. You need to be a site collection admin on the site you are executing the script on.

Update 14-10-2022: I claimed that you could do this using the SharePoint admin role as well. A reader verified this and corrected me: you do need to be 'site collection admin' in all scenario's, thanks Gerben!

You can also:


    # List the existing app permissions that are assigned to the SharePoint site:
    m365 spo site apppermission list --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --siteUrl "https://contoso.sharepoint.com/sites/project-x"

    # Update existing permissions to another permission type:
    m365 spo site apppermission add --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --permission read --siteUrl "https://contoso.sharepoint.com/sites/project-x"

    # Remove the assigned app permissions from the SharePoint site:
    m365 spo site apppermission remove --appId "ce6bb9a7-c909-4538-b9dd-930724d7259d" --siteUrl "https://contoso.sharepoint.com/sites/project-x"
     

There’s currently four types of permissions that can be granted. They match the available app-only scopes in Azure AD:

  1. read - Read items in a site collection
  2. write - Read and write items in a site collection
  3. manage - Read and write items and lists in a site collection
  4. fullcontrol - Have full control of a site collection
Note: When reading the documentation for the Graph API it seems like there should be an 'owner' role instead of 'manage' and 'fullcontrol'. However, the owner role does not work. I've created an issue on GitHub to request changes in the documentation.

PnP.PowerShell

If you are more into using PnP.PowerShell , you can achieve the same. But you need to execute two commandlets. First grant Read or Write permissions. Then update it to Manage or FullControl:


    Connect-PnPOnline -Url "https://contoso.sharepoint.com/sites/project-x" -Interactive

    $permission = Grant-PnPAzureADAppSitePermission -AppId "ce6bb9a7-c909-4538-b9dd-930724d7259d" -DisplayName "TestApp" -Permissions Write -Site 

    Set-PnPAzureADAppSitePermission -PermissionId $permission.Id -Permissions FullControl
     

…as an application

What I explained above is all about a user adding permissions for an application. But what if you want to automate that? It could be necessary in certain scenario’s to do so. You can in fact do this, but you would need another Azure AD Application Registration with the Sites.FullControl.All app-only permission scope to be able to configure it. This kind of seems to defeat the purpose, but there are cases where it is a good setup. For example: the application that assigns app permissions for other applications may run on a different system where extra care has been taken to avoid security pitfalls.

Step 3: Connect to SharePoint

Having set this all up, the only thing that’s left is to let your application connect to SharePoint. You can do this through Managed Identity (when running an Azure Function, Automation Runbook or App Service), or through a Client Certificate. There are a lot of roads to get connected, using various programming or scripting languages, I won’t go into that here today. But I have blogged about running the CLI for Microsoft 365 on an Azure Function earlier, that is a nice example where RSC would be useful!

Wrapping up

Assigning ‘God mode’ to an application on SharePoint should be avoided whenever possible. Fortunately we can restrict permissions to specific SharePoint sites, using Resource Specific Consent. The CLI for Microsoft 365 and PnP.PowerShell offer easy to use tools to get this set-up.

If you have any questions, please drop me a post!

Sources


sharepoint azuread cli-microsoft365 pnp-powershell security
Support me by sharing this

Comments

More

More blogs

Getting notified of changes in guests accessing SharePoint
Getting notified of changes in guests accessing SharePoint

Part 3 on how to use the CLI for Microsoft 365 and Azure Functions: How to get notified of updates in guests accessing SharePoint.

Read more
SharePoint Guest Access and Azure AD B2B
SharePoint Guest Access and Azure AD B2B

Microsoft is polishing up SharePoint guest access, and this is why I find that a big deal.

Read more
How to copy views in SharePoint
How to copy views in SharePoint

There's currently no way to copy list and library views in the SharePoint UI. I've created a SPFx sample demonstrating how it can be done using code.

Read more

Thanks

Thanks for reading

Thanks for reading my blog, I hope you got what you came for. Blogs of others have been super important during my work. This site is me returning the favor. If you read anything you do not understand because I failed to clarify it enough, please drop me a post using my socials or the contact form.


Warm regards,
Martin

Microsoft MVP | Microsoft 365 Architect

Microsoft MVP horizontal