Category Archives: Azure

Automating Sites.Selected permissions provisioning

Scenario

You administer Microsoft 365 SharePoint Online. Part of your daily activities is providing Microsoft Graph and SharePoint Sites.Selected API permissions to other users (developers).

In Aug/Sep 2023 Microsoft pushed an update that prevents site collection admins to create or update an Azure Access Control (ACS) principal (that was the way most of developers used to get Client Id and Client secret to access SharePoint site). So your users are probably getting something like Your SharePoint tenant admin doesn’t allow site collection admins to create or update an Azure Access Control (ACS) principal message attempting to create or update SharePoint App-only principal at AppRegNew.aspx or AppInv.aspx pages. Here are more details on the issue.

Microsoft and MVPs shared some technique how to provide Sites.Selected API permissions, but dealing with scripts manually, elevating individual permissions every time you need to run the script – it all takes time and not very efficient. More and more devs are reaching you on the app. So you want to automate this process.

Solution

Solution architecture

My way to automate it includes:

SharePoint list as a frontend
here you can accept intake requests, organize approval workflow and display automation results
Azure Function App as a backend
here will be your PowerShell script hosted that runs on scheduled basis and takes care of actual permissions provisioning

Solution details

High-level, getting application permissions to some specific SharePoint site is a two-step process:

get application registration in Azure and properly configure it
get permissions for this application to a specific SharePoint site

For the first step – check this and this articles. I’ll focus on the second step below.

You can provide Sites.Selected permissions for the app to a site with

Graph API Site Permissions resource (see also PowerShell code samples)
PnP.PowerShell: Grant-PnPAzureADAppSitePermission

I will be using second one one. Also PnP.PowerShell will be used to get access to SharePoint intake site and read/update requests from SharePoint list and so on.

Azure App Registration

I registered an admin Application in Azure – “SharePoint Automation App”, added Graph Sites.FullControl.All and SharePoint Sites.FullControl.All permissions, then added Microsoft Graph Directory.Read.All permissions and got tenant admin consent:

I generated a self-signed certificate and added it to the app:

This app will be used to call provide permissions, and to connect to the SharePoint front-end.

Users will register their applications in Azure, add Graph Sites.Selected and SharePoint Sites.Selected permissions, got tenant admin consent, then request permissions to the specific site by creating an intake request – new list item.

Front-End SharePoint Site

I created a SharePoint site for automation. This site will play a front-end role for users. I created a list “Sites.Selected” and updated list columns so I have the following fields:

Target Site Url
Application Id
Permissions (read/write)
Automation Output

In real-world (Prod) – You can (should) also implement approval workflow as you’d provide permissions for the application to the site only with this site owner approval. The PowerShell code behind should also validate site owner’s consent with app access to site. But for the sake of simplicity I’ll skip this in my demo.

Azure Function App

I created an Azure Function App with the following parameters:
– Runtime stack: PowerShell Core
– Version: 7.2.
– OS: Windows
– Hosting plan: Consumption

And then PowerShell timer-triggered function in Visual Studio Code.

Function requirements.psd1 (it takes a few hours for Azure to install modules; while modules are installing – you might see “[Warning] The first managed dependency download is in progress, function execution will continue when it’s done. Depending on the content of requirements.psd1, this can take a few minutes. Subsequent function executions will not block and updates will be performed in the background.”):

@{
    'Az' = '10.*'
    'PnP.PowerShell' = '2.*'
}

Azure Az module to access other Azure resources. PnP.PowerShell module will be used to access SharePoint.

I will keep my admin Azure registered app in a key vault, so need somehow to let the key vault know that this specific app can access this specific credentials. So I enabled system assigned managed Identity for the Function App:

MS: “This resource is registered with Azure Active Directory. The managed identity can be configured to allow access to other resources…”.
I’m going to use an object (principal) Id of this function to grant access to keyvault.

Azure key vault

Surely we do not hard-code app secrets. So we need a key vault o store app credentials.

I created a key vault under the same resource group in Azure and named it “SharePointAutomationDemo”. Then I added a roles assignment – “Key Vault Secret User” and “Key vault Reader” to the Function App via it’s managed identity:

I also assigned “Key Vault Administrator” role to the user (developer) who will add certificates/secrets to this key vault and develop Azure function code.

Microsoft Forms Troubleshooting

Deleting user who owns forms

When a form owner account is deleted from AAD

Deleting a group that owns forms

Audit log events

ListForms – Listed forms – viewed forms home page with list of forms
ViewForm – Viewed Form –
ViewRuntimeForm – Viewed response page
ViewResponses- Viewed responses
CreateResponse – Created response
ExportForm – Exported form – “export to excel” – file saved to the local machine (form owner=user)
ConnectToExcelWorkbook – Connected To Excel Workbook – “export to excel” – file saved to the teams SharePoint site under Documents (form owner = group)
EnableSameOrgCollaboration –

How to find Microsoft forms form owner

(credit goes to Tomasz Szypula @toszypul )


toszypul   replied to  Jason_B1025
‎Jan 03 2022 03:17 AM - edited ‎Jan 03 2022 03:18 AM 

@Jason_B1025 I was able to get the ID of the user with a bit of a hack. Here are sample steps:

-Access the form using this designer direct URL https://forms.office.com/Pages/DesignPage.aspx?origin=shell#FormId=<YourFormID>

-Inspect the network traces. You will find a request similar to this 

https://forms.office.com/formapi/api/72f988bf-86f1-41af-91ab-2d7cd011db47/users/e5351c57-d147-418e-89ab-3a3d50c235b6/light/forms('v4j5cvGGr0GRqy180BHbR1ccNeVH0Y5Bias6PVDCNbZUOUg4TkZJUEswSVQ1ODhNNkpHVVlMMldPTi4u')?$select=id,... 

-The ID in bold is the AAD ID of the user
-Use Graph Explorer - Microsoft Graph to run this request to retrieve the username and email address of the owner https://graph.microsoft.com/v1.0/users/<UserID>

How do I know – is it a person-owned or group-owned form

Let say you got a “collaborators” link to the form – so you can edit form, view responses etc. But how to determine who owns the form – person or group.

It is a form owned by person if

form id is 80 characters length
on “Export to Excel” button – it saves/downloads excel file to the file system
“Export to Excel” button generates ExportForm – Exported form event in the audit log
network trace contains “https://forms.office.com/formapi/api/<tenantId>/users/<UserId>/…”

It is a form owned by group

form id is 88 characters length
on “Export to Excel” button – it saves excel file to the team SharePoint site and opens it in browser
“Export to Excel” button generates ConnectToExcelWorkbook – Connected To Excel Workbook event in the audit log
network trace contains “https://forms.office.com/formapi/api/<tenantId>/groups/<GroupId>/…”

Manage Microsoft 365 groups membership with PowerShell and Graph API

1 Reply

As SharePoint or Teams admin you can manage Microsoft 365 groups (create, update, delete, manage membership etc.) having your admin role activated. I use Azure registered app with “Group.ReadWrite.All” Microsoft Graph API delegated permission and Microsoft.Graph PowerShell module.

When a user was not a group member or group owner – and is added to the group members – user gets notification “You’ve joined the <Group Name> group” via e-mail that comes from a group e-mail address.

When a user is added to the group owners (or elevated to group owner if user was a group member) – user does not get notification.

When a user was a group owner and now is added to the group members – user does not get notification.

All the actions are logged into Microsoft 365 audit log under your personal Id.

Script samples:

# This script is just a sample to demonstrate basic technique on deletion m365 groups with PowerShell and MS Graph
# please do not run this script as is, but update it upon your needs

# authentication with personal Id
#  app must have as minimum "Group.ReadWrite.All" Microsoft Graph API delegated permission
#  user must have SharePoint admin (or Teams admin) roles activated
Connect-MgGraph -ClientId $clientid -TenantId $tenantId 
Get-MgContext | Select-Object Scopes -ExpandProperty Scopes

# sample data
$groups = @()
$groups += [PSCustomObject]@{GroupId = '443d22ae-683a-4fe4-8875-7bd78227a026' }
$groups += [PSCustomObject]@{GroupId = 'e5805388-c18c-48c0-b42d-6223cf8f3d82' }

# Get Groups
foreach ($group in $groups) {
    Get-MgGroup -GroupId $group.GroupId
}

# add members to the group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
$userId = 'df74e0d3-d78c-495b-b47a-549437d93cf7' # Adele
New-MgGroupMember -GroupId $groupId -DirectoryObjectId $userId

# add Owner to the group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
$userId = 'eacd52fb-5ae0-45ec-9d17-5ded9a0b9756' # Megan
New-MgGroupOwner -GroupId $groupId -DirectoryObjectId $userId

# Delete group
# add Owner to the group
$groupId = '443d22ae-683a-4fe4-8875-7bd78227a026'
Remove-MgGroup -GroupId $groupId

https://github.com/VladilenK/m365-PowerShell/tree/main/KBA/Ownerless-Groups

Microsoft 365 ownerless group policy to send more than 10,000 notifications

1 Reply

It is known that a single Microsoft Exchange account is not sending more than 10k emails per day.

It is also know that once activated – Microsoft 365 groups ownerless policy will be sending notifications for all groups in scope to specified number of group members within 24 hours.

The question is: what if there are more than 10,000 notifications to send (e.g. 4,000 ownerless groups and the policy is configured to send notification to 3 members per group – that gives us 12,000 notifications to send)? Would the policy send 10k notifications and the rest 2k notifications the next day?

I’m conducting an experiment. I created 10k groups in my lab tenant with one owner and 3 random members. Then I configured a policy that is sending notification to a 3 most active members (in this case – random members). And then I made all these groups ownerless by deleting the single owner Id from Azure AD (Microsoft Entra).

Here is what I got from users perspective:

user	user groups number	got messages day 1	got messages day 2	got messages total
1 Roger	5012			1374
2 Dick	5039			1349
3 Bob	5108			3412
4 Bapu	4908			1376
5 Stas	4996			1437
6 David	4959			1377
total				10325

Here is what audit log says:

Events “OwnerlessGroupNotified” day 1: 4949
Events “OwnerlessGroupNotified” day 2: 95
Events “OwnerlessGroupNotified” total: 5044
Each event details says 3 members were notified.

It seems like groups are selected by policy in random order.

Massive E-mails sending was started 43 minutes after midnight UTC

“OwnerlessGroupNotified” were logged at the rate of
1925 events during 1-st hour,
2029 events during 2-nd hour,
785 events during 3-rd hour,
176 events during 4-th hour,
26 events during 5-24 th hour,
95 events during next 25-48 hours
so max rate was one event every 3 seconds in the beginning (or 1 e-mail per second) …

TBC…

Your SharePoint tenant admin doesn’t allow site collection admins…

2 Replies

Scenario

You are trying to register an application at SharePoint site with appregnew.aspx page and you are getting an error or notification message “Your SharePoint tenant admin doesn’t allow site collection admins to create an Azure Access Control (ACS) principal“.

Your SharePoint tenant admin doesn't allow site collection admins to create an Azure Access Control (ACS) principal. Please contact your SharePoint tenant administrator

You are trying to provide ACS-based permissions for an application to SharePoint site with appinv.aspx page and you are getting “Your SharePoint tenant admin doesn’t allow site collection admins to update app permissions. Please contact your SharePoint administrator.”

Your SharePoint tenant admin doesn't allow site collection admins to update app permissions. Please contact your SharePoint tenant administrator

Reason

This is due to a security measures enhancement MC660075 in Microsoft 365 tenant governance recently implemented by Microsoft. According to the update, only tenant administrators can create or update ACS service principal by default.

The root cause for this is that the Microsoft is pushing developers to Azure-registered applications with Sites.Selected API permissions as they are more secure that legacy ACS-based service principals.

Key differences ASC vs Sites.Selected are:

ACS-based SharePoint app/permissions	Apps registered in Azure with Sites.Selected API permissions
support authentication with client secret only, secret is valid for 1 year exactly	support authentication with client secret and certificate, custom expiration time
support granular access to SharePoint at the site-level e.g. to site collection or web or a specific list	support only access to entire site collection (but Microsoft is working on granular access)
support only classic SharePoint REST API and CSOM	support both – classic SharePoint REST API and CSOM and Microsoft Graph API
app id (client id) is created via appregnew.aspx at a specific SharePoint site by site collection administrator	app id (client id) is created in Azure portal, API Sites.Selected permissions are configured via Azure portal and require tenant admin consent
permissions for the app to a site are provided at the site by site collection administrator via appinv.aspx page	permissions for the App to to a specific SharePoint site are provided by SharePoint admin with PowerShell script or Graph API calls

Solution

Register an application in Azure (via Azure portal GUI, PowerShell script or your company’s specific helpdesk/servicedesk request)
Update the app so both – MS Graph API Sites.Selected and SharePoint Sites.Selected permissions are configured and
API permissions must be consented – so you’d seek/request your tenant admin consent
Obtain and upload client certificate (recommended) or generate client secret
Request access for the app to a specific SharePoint site (your SharePoint service admin should be able to do that)
Validate your app has access to the target SharePoint site with PowerShell
Secure your certificate and/or secret

If you are hosting your application in Azure – consider using managed identity.

Sites.Selected API permissions for SharePoint access

1 Reply

Sites.Selected permissions are needed for the non-interactive application to get access to a specific SharePoint site.

Steps to get access to SharePoint site with Sites.Selected:

1. Register an application in Azure (via Azure portal GUI, PowerShell script or helpdesk/servicedesk request)

2. Update the app so both – MS Graph API Sites.Selected and SharePoint Sites.Selected permissions are configured and consented by tenant admin

3. Obtain and upload client certificate (recommended) or generate client secret

4. Request access for the app to a specific SharePoint site (your SharePoint service admin should be able to do that via PowerShell script or Graph API calls )
Here is the Graph API

5. Validate your app has access to the target SharePoint site with PowerShell
tbp

6. Secure your certificate and/or secret

Consider using vault to keep certificate/secret. If you host your application in Azure – consider using managed identity

ACS-based permissions are going to be deprecated soon:
Your SharePoint admin doesn’t allow site owners to create/update ACS principal ⋆ Vladilen Microsoft 365 engineer

Connecting to Microsoft 365 SharePoint and Graph API from Azure Function App

Implementing Microsoft 365 group expiration policy in large companies

1 Reply

WIP

Scenario

Let say you administer a large Microsoft 365 environment (e.g. ~100k+ users and/or ~50K+ sites) and after some years you have a lot of ownerless groups and sites (around 5k probably), and a lot of inactive groups and sites (maybe 15k). And new ownerless groups are coming at a pace of dozens per week? You a thinking of stopping bleeding and cleaning this up…

Out-of-the-box we have Microsoft 365 groups expiration policy and Microsoft 365 ownerless groups policy. You might also have some 3-rd party tools implemented – e.g. ShareGate, SysKit.

If you do not care – you might just activate both OotB Microsoft policies – via GUI – they are simple to activate. But once you activated policies – they will trigger thousands of emails. Now imagine a person is getting dozens of emails asking him/her to be an owner or to renew the group that maybe does not make much sense… What’ll happen? Right, people will probably ignore these notifications. What will happen next? Groups and sites will be automatically deleted. And then? Right, there will be a noise and many angry users and high-priority tickets and you will have to restore sites/teams and finally you’ll have to look for groups owners manually.

So, what is the right way to clean-up a large Microsoft 365 environment from ownerless and inactive teams, groups sites?

Not a trivial question, hah?

Solution

Disclaimer: I’m sharing here my personal opinion with no obligations or warranty etc., so you’d dig into all the technologies used and based on your particular situation build your own plan.

It’d be a good idea to discuss it with you org’s communication team and helpdesk/service-desk to adjust clean-up activities with other initiatives and let other people be prepared.

High-level steps for group-based Sites:

consider implementing Minimum 2 owners per group policy to stop bleeding and apply this policy to groups where you already have 2+ owners – it’ll be safe; currently Microsoft does not have such functionality, so consider 3-rd party tool like SysKit
consider custom PowerShell clean-up, e.g. you can simply delete groups with no owners and no members and/or inactive groups with no content and/or groups that are inactive for a long time (this must be aligned with business and legal)
implement Microsoft’s Ownerless group policy in “Clean-Up” configuration; there are some tricks and gotchas worth a separate post, but in short
- avoid scoping down this policy via people (security groups)
- implement it for all groups all users with 6-7 weeks and custom e-mail template
implement Microsoft groups expiration policy in “Clean-Up” configuration… again, there are a few different strategies – see below
change Microsoft Ownerless groups policy configuration to a “Permanent” mode configuration set
change Microsoft 365 groups expiration policy with a “Permanent” mode configuration

All above was mostly about group-based sites (as we have OotB Microsoft policies for groups), but we probably have the same problem (or even worth) with standalone sites (TBC).

Implementing Microsoft 365 groups expiration policy

If you are thinking of activating in an existing environment – you would probably have a spike – all the old groups will be subject to policy. The ide is to avoid situation when a specific person – group owner will get dozens of email. It would be better if a person will receieve, let say one email per week.

Here is my 4 possible approaches to avoid this spike, distribute notifications evenly across the time and ease the pain:

By changing Group Lifetime

You would need to change the policy every, e.g. week, specifying different group lifetime in days period. Consider
– calculate number of days between the oldest group created an today, plus 35 days – it’ll be your first “group lifetime”
– activate the policy with this number of days in “group lifetime” – and within a week you will get notifications on the oldest group/groups
– after a week or two – change the “group lifetime” decreasing it by e.g. 30-60 days and reactivate the policy… and so on

You can easily calculate it all and choose your pace depending on how many groups you have to renew, how much time you need to clean-up. You got the idea.

Downside – in the email notification it will be said “otherwise the group will be deleted on …”, but once you start joggling with dates – this will not be true probably.

By renewing groups as admin

tbp

By sending customized e-mails to users

tbp

By sending users to the groups page

tbp