SharePoint Server – OIDC Authentication – Using Groups for Permission

Posted On March 19, 2024

Overview

It’s much more efficient to use groups to assign permissions than individual users. If you followed the steps in Set up OIDC authentication in SharePoint Server with Microsoft Entra ID to configure OIDC authentication, then on the SharePoint Server side, only a single identity claim was mapped. This article will walk you through adding groups to that setup.

Environment

Add groups in Entra ID

Log on to the Entra ID portal for your tenant (https://entra.microsoft.com/) and go to Applications | App Registrations | < The app registration you created to enable OIDC in your SPSE farm >.
Click on "Token Configuration", and then "Add groups claim".

This is where you’re going to have to do some planning to select what’s "right" for your environment. There’s 4 different group / role types to choose from (and you can do combinations), and a number of options for which value you’d like to send as the group / role claim. What you select here impacts how you configure the Trusted Identity Token Isser and Claim Provider (people picker) on the SharePoint Server side.

For example, "Group ID" should work for cloud-only groups and groups synched from an on-premises Active Directory (AD), whereas the other options that include sAMAccountName or "On Premises Group Security Identifier" only work for groups synced from an on-prem AD because groups created directly in Entra ID (cloud-only) groups don’t have those values.
See these articles for more information:

Important! Near the top of Configure group claims for applications by using Microsoft Entra ID, you should see this:

This is a very important consideration. If a user is a member of more than 200 groups, their OIDC JWT token will not contain ANY group claims, which means they will not be granted any access to SharePoint via group membership.

Choose Group Type

In this example we’re interested in sending both cloud-based groups and AD-synched groups, so we’ve selected Group ID. We’re also going to select the "Emit groups as role claims" option, so that we can use the more familiar "Role" claim mapping instead of a "groups" claim mapping.

Add groups to Trusted Identity Token Issuer

On the SharePoint Server side, we must add the "Role" claim to the existing trusted provider since that’s the claim type we just configured Entra ID to send. You do that with PowerShell. In the following example, the name of my trusted provider is "ODIC".

# Add Role Claim
$Trust = Get-SPTrustedIdentityTokenIssuer -Identity "OIDC"
$Trust.ClaimTypes.Add("roles")
$Trust.Update()

# Add the claim mapping
$roleClaim = New-SPClaimTypeMapping -IncomingClaimType "roles" -IncomingClaimTypeDisplayName "Role"  -LocalClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
Add-SPClaimTypeMapping  –TrustedIdentityTokenIssuer $Trust –Identity $roleClaim

Then you can use the following PowerShell to check the claim mappings for your trusted provider.

# Check claim mappings
$Trust = Get-SPTrustedIdentityTokenIssuer -Identity "OIDC"
$trust.ClaimTypeInformation

We can see that the "role" claim has been added.

Add Permission in SharePoint

Now that we’ve configured Entra ID to pass role claims, and SharePoint Server to accept them, we need to add permission to our site for our group. I created a group directly in Entra ID called "TestGroup1". Since we chose "Group ID" earlier as the claim value to pass, I must use the Object ID of the group to give permission in SharePoint.
Since I do not currently have a custom claim provider (CCP) installed in my farm, I must enter the Group ID value into People Picker. In Entra ID, I can see the "Object ID" value is 8a275cbb-9558-4e3f-b5f5-ba9b1e597353. That is the Group ID.

So that’s what I enter into People Picker. Since I have more than one claim mapped (email and groups), and no custom claims provider installed, I get "multiple entries matched, please click to resolve".

If I hover over them, I see one is for Email, and one is for Role. I want to select Role since it’s a Group ID, and not an email address.

Now I see that added to my site permissions. If I click on it, I can see then entire claim name.

Now that I’ve added that role to site permission, my Entra ID users that are members of that group should be able to access the site and get the site permissions assigned to that group.

Add a Custom Claims Provider

While the instructions above will get site access via Entra ID groups working, the People Picker functionality is not very good. Users would have to know the Object ID (group id) of the group, enter it correctly, and choose the correct claim type when prompted.

In order to select groups using their display name, we need a custom claims provider (CCP). You can elect to create your own, or use a 3rd party CCP like EntraCP.

The steps for configuring EntraCP are well-documented, so we won’t revisit them here.

After installing and configuring EntraCP, if everything is configured properly, we should be able to go back to our test site and now use People Picker to find our "TestGroup1" group using its display name.

And it should add it to site permissions using the display name ("TestGroup1").

We see that it shows the display name for the group, but if you click on it, you should see that it’s still using the group ID 8a275cbb-9558-4e3f-b5f5-ba9b1e597353 as the groups account name.

Note: If it still adds the group using the ID as it’s display name, it may be because you previously added it to the site collection using its ID, for example, you added it before you had EntraCP installed. In that case, simply click on the group name like we did in the screenshot above and choose "Delete user from Site Collection". Then add the group back to site permissions.

You can see that with the EntraCP custom claims provider installed and configured, People Pickler functionality is much better.

Add a Comment