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:

Lists.SelectedOperations.SelectedProvides application access to a specific list
ListItems.SelectedOperations.SelectedProvides application access to one or more list items, files, or folders
Files.SelectedOperations.SelectedProvides application access to to one or more files or library folders

Set of SelectedOperations permissions 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 Azure Data Factory did not support modern authentication and 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 Azure Data Factory v2 (ADF V2) supports authentication via app registration with Sites.Selected API permissions, providing Client Id and Certificate. Below are steps to configure ADF v2 connection to SharePoint with a Certificate.

That is how authentication part looks like:

configure ADF v2 connection to SharePoint with a Certificate

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

Microsoft announced EOL of ACS, and we as SharePoint administrators must take actions. ACS retirement as is a really big deal – entire era of SharePoint app-only service principals will be gone. SharePoint developers used ACS apps since 2013 to build solutions, and when it comes to software development – it always takes time. Imaging the code that was designed for ACS now needs to be reviewed and re-written to adopt changes, then re-compiled, re-tested, re-deployed etc. So it is critical that we should take measures now to avoid bigger issues in April 2026.

Recommended transition tactics: for developers

  • Get a new App Registration in Azure (Entra Id) with Sites.Selected permissions, ensure no ACS permissions provided to the app (see details on Sites.Selected) and use it
  • Prioritize using Microsoft Graph API
  • If Graph API does not provide required functionality – it’s ok to use SharePoint API, but keep in mind in this case certificate should be used (not secret) for authentication

Recommended transition tactics: for SharePoint admins

High-level recommended steps are:

  • Keep saving audit logs
  • Encourage users and developers to register applications in Azure (not in SharePoint)
  • Start providing Sites.Selected permissions
  • Disable ability for site owners to use AppRegNew and AppInv
    Stop registering service principals via AppRegNew and providing ACS permissions via AppInv
  • Pull report on existing Apps that use ACS permissions
  • Notify developers and users of the ACS apps
  • Switch ACS off earlier than Microsoft

Thinkin on devs – keep in mind:
– ACS apps have a huge legacy – tons of articles and code examples and so on…
– Switching to a modern authentication method would require changes in code (though minor, but still), so developers must be engaged
– Any change in code would require another round of code compilation, testing, deploying etc.

That means it is not easy (sometimes it is not even possible) to adopt a new modern authentication method. It requires efforts and time, so you need to notify dev as earlier as possible. So it is crucial to complete steps above and start communicating to users as earlier as possible.

Detailed steps for SharePoint administrators:

Keep audit logs

This should be done in advance, but if you did not – starting today and until it’s over you’d get audit logs from Microsoft 365 purview center – consider selecting all events with record type SharePointAppPermissionOperation. Also might be helpful to keep events anyone visited appinv.aspx or appregnew.aspx page. Pull logs now starting with earliest available event (usually 90 days). Some audit logs are available only through Microsoft Graph API. See more details regarding audit logs for ACS tracking KBA.

Encourage users registering applications in Azure (not in SharePoint)

Creating App Registrations in Azure is usually not what SharePoint admins do. Sometimes users are allowed to register apps, sometimes it is blocked for a regular user and done by identity management (or so) but the main idea – users and developers should be able to get service principals (App Registrations) in Azure. Users would need Sites.Selected permissions consented (see more about Sites.Selected) or granular permissions consented (more on granular permissions to SharePoint).

Some pro’s of App Registered in Entra Id (vs SharePoint App-only service principals):
– It supports authentication with client secret and/or certificate, custom expiration time
– It supports both APIs – Microsoft Graph API and classic SharePoint REST API

Be prepared to instruct users how to get and use certificates in their app registrations.

Provide Sites.Selected permissions

99% of requests for application permissions to SharePoint would require access to a specific site (sites), or to a specific list/library/folder/file (but not to entire tenant). So consider providing Sites.Selected permissions by default (or granular permissions when they are in GA). Create a process so users can request permissions to SharePoint sites for their Azure-Registered Apps. Consider automation if you are a large company (here is one of the possible Sites.Selected automation solutions).

Inform user that ACS is deprecated and you do not provide any new ACS permissions.

Disable registering new service principals in SharePoint

Once you are good in providing non-ACS permissions, it’s time to disable registering service principals in SharePoint. Users should not be able to get a new SharePoint App-only service principals (apps that they used to get from SharePoint sites just going to AppRegNew.aspx).

Disable ability for site owners register service principals in SharePoint via appregnew.aspx is done via 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. Using AppInv.aspx page will also be disabled for site owners. Your users will start seeing “Your SharePoint tenant admin doesn’t allow site collection admins…” message (see details), but that’s ok.

There might be rare cases when your in-house solutions or 3-rd party apps got their secrets expired and would require new legacy ACS-based permissions, it is tempting to allow ACS permissions as an exception (as technically it is possible for SharePoint service admin to provide ACS-based access to sites), but I would strictly discourage you to do so. If you decide to provide ACS – track this activity (so you know for whom this ACS-based permissions were provided).

Pull report on existing ACS Apps that use ACS permissions

You need to know who are your vulnerable clients – you should pull reports to get a list of existing Apps that use ACS permissions, apps owners, maybe sites these apps have access to and sites owners

You can get list of developers combining
– audit log data from Admin Center and Graph API
– report from Entra Id on apps and owners
– report from SharePoint sites on permissions provided for apps
– reports generated by PnP Microsoft 365 assessment tool

Here is the detailed KBA on how to get reports on legacy ACS service principals usage in tenant

Consider the following steps to get ACS apps owners

  • get ACS apps with permissions using Microsoft 365 assessment tool
  • pull these apps owners from Entra Id
  • using Graph API audit logs data – mark apps active/inactive based on date of the latest login

Notify developers and users of the ACS apps

From the step above we can have a lost of legacy ACS apps and their owners, as well as apps activity (last login), so we can start communicating developers (app owners):

  • As earlier as possible – e.g. in March-April 2025 (1 year before ACS EOL), notify all apps owners that they need to transition to Azure apps and Selected permissions
  • Get ACS apps activity and repeat communication, including active app owners
  • Get ACS apps activity and repeat communication, including owners of sites apps still have access to
  • Communicate to all apps owners that there will be a temporary and permanent shut down of ACS (see below)
  • I case you have ACS apps with tenant-level permissions – communicate to them separately

    Switch ACS off earlier than Microsoft

    You need to plan actual ACS apps disablement in tenant in advance – earlier than Microsoft will do it (in case Microsoft will not put it off). Also consider temporary switch off ACS (“scream test”) even earlier, let say, starting September 2025.

    Temporary and permanent ACS disablements before official ACS EOL are needed as scream tests – in case there are users who ignored all communications and still use ACS apps. Disabling ACS early may cause problems with existing applications, but it is necessary to avoid more serious consequences when the time comes for Microsoft to turn it off. So be prepared to handle tickets and communicate to apps owners in advance.

    This might be your draft plan:

    • schedule the first and 2nd temporary (e.g. during 1 hour) ACS apps disablement ~ 6 and 5 months before EOL
    • schedule the 3rd and 4th temporary (e.g. during 24 hours) ACS apps disablement ~ 4 and 3 months before EOL
    • schedule the full (permanent) ACS apps disablement ~ 2 months before EOL

    References

    PowerShell Script for Files Deduplication

    If you think you have a lot of duplicated files that consumes your hard drive storage space, this article is for you. Personally, I have a lot of video and pictures on my working hard drive and on a backup HDD. While working with photos and videos I can rename files, copy or move them from folders to folders. As a result, I end up with gigabytes and terabytes occupied with duplicated files. So I need a tool to a) find duplicated files and b) remove duplications. I tried to find good scripts but somehow I was not happy with what I found, so I wrote scripts myself.

    Surely you can buy/try a 3-rd party toot with GUI, but if you are comfortable with PowerShell – consider the following.

    References