Category Archives: SharePoint

SelectedOperations.Selected permissions in SharePoint

Microsoft says “Initially, Sites.Selected existed to restrict an application’s access to a single site collection. Now, lists, list items, folders, and files are also supported, and all Selected scopes now support delegated and application modes.”. This article deep-dives into providing and using SelectedOperations.Selected granular permissions to SharePoint.

SelectedOperations is exactly what Microsoft promised a few years ago. And this is great, as we really need granular access to SharePoint sites. I’ve been supporting enterprise SharePoint for more than 10 years now, and I know that it was always a concern when application require access to a list/library or a folder or even document, but admins have to provide access to entire site.

Especially, I believe, this feature becomes more in demand because of Copilot for Microsoft 365. As for now – it’s mostly developers and data analytics who needs unattended application access to SharePoint, but what if regular users powered with m365 Copilot license start creating autonomous agents?

So below is my lab setup, PowerShell scripts and guides with screenshots on how to provide granular (not to entire site but to library/list or folder, or even just one document or list item) permissions to SharePoint and how to use provided permissions.

Admin App

First, we need an Admin App – an app we will use to provide permissions.

The only requirement – this app should have Microsoft.Graph Sites.FullControl.All API permissions consented:

Target Site and Dev Setup

For this lab/demo setup, I have created a team under Microsoft Teams (so it’s a group-based Teams-connected SharePoint site), then test list and test library:

There must be an App Registration for client application – application that will have access to Test-List-01 and Test-Lib-01 only. This app registration should have Microsoft Graph “Lists.SelectedOperations.Selected” API permissions consented:

and I will use Python to access SharePoint programmatically.

At this moment (we have a client app and secret, and “” API permissions, but did not provide for this app access to specific sites or libraries) – we should be able to authenticate to Microsoft 365, but not able to get any kind of data (we can get token, but other call to Graph API would return 403 error – Error: b'{“error”:{“code”:”accessDenied”,”message”:”Request Doesn\’t have the required Permission scopes to access a site.”,):

PowerShell script to provide selectedoperations.selected access for an app to a specific list would be as below. Here we use plain calls to MS Graph API. Full script for your refence is available at GitHub, but here is the essential part:

$apiUrl = "https://graph.microsoft.com/beta/sites/$targetSiteId/lists/$targetSiteListId/permissions"
$apiUrl 
$params = @{
	roles = @(
	    "read"
    )
    grantedTo = @{
        application = @{
            id = $clientAppClientId
        }
    }
}
$body = $params | ConvertTo-Json
$response = Invoke-RestMethod -Headers $Headers -Uri $apiUrl -Method Post -Body $body -ContentType "application/json"

Client Application

I use Python console app as a client application. Link to the code at the GitHub is shared below under References, but the core part of the Python code is (I do not use any Microsoft or other libraries here, just plain requests to Microsoft Graph for authentication and for data):

import requests
import json
from secrets import clientSc, clientId, tenantId, siteId, listId 

# specify client id, client secret and tenant id
# clientId = ""
# clientSc = "" 
# tenantId = "" 

apiUri = "https://login.microsoftonline.com/" + tenantId + "/oauth2/v2.0/token"

body = {
    "client_id"     : clientId,
    "client_secret" : clientSc,
    "scope"         : "https://graph.microsoft.com/.default",
    "grant_type"    : "client_credentials" 
}

try: 
    response = requests.post(apiUri, data=body)
    token = json.loads(response.content)["access_token"]
except:
    print("Error: ", json.loads(response.content)["error_description"])
    exit()

print("Got token: ", token[0:10], "...")
headers={'Authorization': 'Bearer {0}'.format(token)}

# Get specific site list
print("Geting specific site list")
# graph_url = 'https://graph.microsoft.com/v1.0/sites/' + siteId + '/lists/' + listId
graph_url = 'https://graph.microsoft.com/beta/sites/' + siteId + '/lists/' + listId
graphResponse = requests.get(   graph_url, headers=headers )
print(" Response status code: ", graphResponse.status_code)
if graphResponse.status_code == 200:
    list = json.loads(graphResponse.content)
    print(" List display name: ", list["displayName"])

Note.
I’m not sure if it’s a bug or my incorrect setup, but I noticed that if I provide access for the app to the list – app can read site.

TBC…

References

Azure Key Vault Purge Protection

Azure key vault is something where you can store keys, secrets, certificates that you’d need to access services (e.g. call Graph API).

What if somebody malicious get access to key vault (that is not what we want but we should consider this as possible risk)? Surely leaked secrets is a serious issue (separate topic), but imagine if that somebody also deletes key vault content – if so, we will simply lose this data, which will break the functionality of the solution and our existing systems will stop working.

So enabling purge protection on key vaults is a critical security measure to prevent permanent data loss. This feature enforces a mandatory retention period for soft-deleted key vault contents (e.g. secrets), making them immune to purging during the retention period.

In a nutshell, you’d just select “Enable purge protection” under the key vault Settings/Properties (notice, that once enabled, this option cannot be disabled):

For details, please refer to the following articles:

References

Automating SharePoint operations with Azure Functions

There are many scenarios for SharePoint or Teams automations, and in most cases you need to run some code on scheduled basis (e.g. every 5 minutes or every 24 hours etc.). This is where timer-triggered Azure Functions might help. In this article I will provide use cases, overview of the whole scenario and technical setup, and provide links to the detailed step-by-step guides for configuring different parts of the entire solution.

Possible scenarios

Possible scenarios (end-user-oriented):

  • Create site upon user request
  • Convert site to a HUB site upon user request
  • Set site search scope upon user request
  • Setup site metadata (site custom properties)
  • Request usage reports/analytics

Possible scenarios (admin-oriented):

  • Provide temporary access to the site (e.g. during troubleshooting)
  • Provide Sites.Selected permissions for the App to the Site
  • Disable custom scripts or ensure custom scripts are disabled
  • Enable custom scripts (e.g. during site migration)
  • Monitor licenses – available, running out etc.

Typical setup

Front-end

SharePoint site works as a front-end. You do not need to develop a separate web application, as It’s already there, with reach functionality, secured and free.

The site can have:
– one or more lists to accept intake requests
– Power Apps to customize forms
– Power Automate to implement (e.g. approval) workflows, send notifications etc.
– site pages as a solution documentation
– libraries to store documents provided as response to requests

You can provide org-wide access to the site if your intention is to allow all users to submit requests or secure the site if you want to accept requests only from a specific limited group of people.

Back-end

Timer-triggered Azure Function works as a back-end. The function can be scheduled to run based on job specific requirements (e.g. every 5 or 10 minutes, or daily or weekly etc.). The function can be written in PowerShell, C#, Python etc.

The function’s logic is to

  • read SharePoint list, iterate through items to get intake requests
  • validate request eligibility
  • perform action
  • share results (e.g. update intake form, send e-mail, save document to library etc.)

Configuration

There should not be an issue to setup a front-end. You’d just need a solid SharePoint and Power Platform skills.

For the back-end the solution stack would include the following tools/skills:
– Azure subscription to host solution
– Registered Apps to configure credentials and API access permissions
– Azure Function App to actually run the code
– Azure Key Vault to securely save credentials
– programming skills in language/platform of choice
– SharePoint API, Microsoft Graph API

Please refer to the separate article Configuring Azure Function App and Key Vault to work with Microsoft 365 SharePoint via Graph API for the basic setup.

Secure

Having basic setup in place, we’d improve solution security. Specifically, we’d address the following:

  • Azure Function network security
  • Key Vault network security
  • Storage Account network security
  • Key Vault purge protection
  • tbc…

TBC…

References

Azure Data Factory: connecting to SharePoint with a Certificate

For a long time we had to provide legacy ACS permissions for Microsoft Azure Data Factory to connect to SharePoint. That’s not the case anymore. Finally Microsoft updated authentication page so ADF V2 supports authentication with Client Id and Certificate, which means that application registration used to connect to SharePoint can have only modern Sites.Selected API permissions.

The steps would be

  1. Obtain a certificate
  2. Get a service principal (Register your app in Entra Id )
  3. Upload the certificate to the app registration
  4. Provide access for the app id (client id) to your SharePoint site
  5. Configure linked service in ADF

Detailed Step-by-Step guide ADF connect to SharePoint with a Certificate

1. Obtain a certificate

There are no special technical requirements for a Certificate. Since this is about trust between two parties and you own both – the certificate can be self-signed (e.g. generated with PowerShell as described here). But some organizations still require all certificates used in an org to be trusted by org CA.

2. Register app in Azure to get a service principal

To get a service principal – Client ID (app id) – your must create a so-called “App registration” in Entra Id (Azure AD). Specific requirements: app should have both – Microsoft Graph API and SharePoint API Sites.Selected permissions configured and consented. The process is described, e.g. here.

3. Upload the certificate to the app registration

Under Secrets and Certificates section of you App Registration – select Certificates tab and upload your certificate.

4. Provide access for the app id (client id) to your SharePoint site

This is something only your admins can do. Having Microsoft Graph API and SharePoint API Sites.Selected permissions configured and consented does not mean you automatically have access to SharePoint. Sites.Selected API permissions presence means you are allowed to get access specific SharePoint sites, but what are these sites and what kind of access?
So you’d request your SharePoint tenant admins to provide access (e.g. read-only or read-write or full control) for your App Id (client id) to specific SharePoint site Urls.
If you are an admin – check this.

5. Configure linked service in ADF

The last step is to configure your Data Factory connection to SharePoint list using service principal and certificate you got earlier with steps 1-4.

References:

Working with SharePoint from Python code via Graph API

Python code samples published by Microsoft at the Microsoft Graph API reference pages use GraphServiceClient module. But you also can use just requests module and call Microsoft graph API directly, using requests.post or requests.get methods. Here I’m sharing my Python code samples.

https://github.com/VladilenK/m365-with-Python/tree/main/Graph-API-Plain

Azure ACS retirement. How to prepare your tenant. Guide for SharePoint Admins.

Since Microsoft announced EOL of ACS in 2026, we as SharePoint administrators must be prepared, as it is a really big deal – entire era of SharePoint app-only service principals will gone. SharePoint developers used this kind of authentication since 2013 to build their solutions. And when it comes to software development – it always takes time. Imaging all the code that was designed since 2013 needs to be reviewed and re-written to adopt changes. So it is critical that we should take measures now to avoid huge problems in April 2026.

Recommended transition tactics

For developers

  • Prioritizing using Microsoft Graph API.
  • In cases Graph API does not provide required functionality – it’s ok to use SharePoint API, but please ensure certificate is used (not secret).

For SharePoint admins

High-level recommended steps are:

  • Encourage users registering applications in Azure (not in SharePoint)
  • Disable ability for site owners register service principals in SharePoint via appregnew.aspx
    Your users will start seeing “Your SharePoint tenant admin doesn’t allow site collection admins…” message (see details), but that’s ok.
  • Create a process so users can request permissions to SharePoint sites for their Azure-Registered Apps. Provide Sites.Selected permissions by default. Consider automation.
    In rare cases when 3-rd party apps require legacy ACS-based permissions, it would be you (SharePoint service admin) who will provide ACS-based access to sites.
    Track this activity (so you know for whom this ACS-based permissions were provided).
    Inform every developer that ACS will be gone.
  • Keep audit logs
    Starting today and until it’s over you’d get audit logs from Microsoft 365 purview center – consider selecting all events anyone visited appinv.aspx page.
  • In March-April 2025 (1 year before) ACS EOL, start notifying developers who use ACS.
    You can get list of developers combining
    – audit log data
    – report from Entra Id on apps owners
  • In advance ( let say, starting September 2025) you can try to temporary switch off ACS (“scream test”).

Detailed steps:

Encourage users registering applications in Azure (not in SharePoint)

Pro’s for App Registered in Entra Id (vs SharePoint Apps-only service principals – apps registered in SharePoint with AppRegNew.aspx) :

  • Support authentication with client secret and/or certificate, custom expiration time
  • Support both – classic SharePoint REST API and CSOM and Microsoft Graph API

Disable registering service principals in SharePoint

Disable ability for site owners register service principals in SharePoint via appregnew.aspx with Set-SPOTenant PowerShell cmdlet

Set-SPOTenant -SiteOwnerManageLegacyServicePrincipalEnabled $false
When the value is set to false, the service principal can only be created or updated by the SharePoint tenant admin. Your users will start seeing “Your SharePoint tenant admin doesn’t allow site collection admins…” message (see details), but that’s ok.

tbc

References