Roles (security groups) with SAML/ADFS will not work with OAuth without some more configuration and patching. OAuth affects 2013 Workflows, Office Web Apps, Provider Hosted Apps, Cross Farm Publishing/Consuming scenarios, Hybrid, etc. There are a few steps and requirements that are needed for this to work. KB 3203164 has some great information on this topic on setting the GroupClaimType.

NOTE: SharePoint 2013 must at (or later) March 2016 CU (15.0.4805.1000). SharePoint 2016 introduces the GroupClaimType with the September 2017 (16.0.4588.1000, Feature Pack 2) but we suggest deploying January 2018 PU (16.0.4639.1001) due to the regression causing Windows Claims Oauth augmentation to fail.

User Profiles are Key

User profiles are utilized when augmenting the role claims. The groups and users must be imported and synced within the User Profile Service application.

Map your Identifier claim

Run this PowerShell script to find the identifier claim:

Example of the script results when Email was the Identifier claim:

In the User Profile Service Application à Manage User Properties, edit the properties of the Claim User Identifier.

SharePoint 2016’s Active Directory Import automatically maps Claim User Identifier to saMAccountName. We would need to change that to correct identifier property in Active Directory. Any change in mappings will require a full sync.

Adding a new mapping for the identifier claim:

Group Membership in User Profiles

There are two ways to get this information – SQL or PowerShell. The PowerShell one will show nested groups unlike the SQL query.

Run this against your Profile Database and modify the domain\username to fit the user profile that we are searching for. This information would be in the UPA when searching for a User Profile.

SQL – SharePoint 2016

Select upa.UserProfile_Full.NTName, upa.MemberGroup.DisplayName as ‘Group Name’, upa.MemberGroup.SourceReference

From upa.UserProfile_Full with(nolock) JOIN upa.UserMemberships on upa.userprofile_full.RecordID = upa.UserMemberships.RecordID

Join upa.MemberGroup on upa.Usermemberships.MemberGroupId = upa.Membergroup.ID

Where NTName = ‘domain\username’

SQL – SharePoint 2013

Select UserProfile_Full.NTName, MemberGroup.DisplayName as ‘Group Name’, MemberGroup.SourceReference

From UserProfile_Full with(nolock) JOIN UserMemberships on userprofile_full.RecordID = UserMemberships.RecordID

Join MemberGroup on Usermemberships.MemberGroupId = Membergroup.ID

Where NTName = ‘domain\username’

Bdoe has 5 group memberships in the UserProfile service application.

PowerShell

$site = Get-SPSite “http://adamsor-2013upa”

$userprofile = “i:05.t|adfs|user@contoso.com”

$ServiceContext = [Microsoft.SharePoint.SPServiceContext]::GetContext($site);

$pm = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($ServiceContext)

$up = $pm.GetUserProfile($userprofile)

[xml]$xml = ($up.Memberships.GetDataSet()).getxml()

$xml.SelectNodes(“//Title”)

Output:

GroupClaimType

This property shown when running Get-SPTrustedIdentityTokenIssuer

As KB 3203164 states, we only have two options, the Role or GroupSID for claims.

PowerShell:

#Create a variable containing the SPTrustedIdentityTokenIssuer object
$issuer = Get-SPTrustedIdentityTokenIssuer

#Set the GroupClaimType property to the Role claim type, do not run for GroupSID claim type
$issuer.GroupClaimType = [Microsoft.IdentityModel.Claims.ClaimTypes]::Role

#Set the GroupClaimType property to the GroupSID claim type, do not run for Role claim type
$issuer.GroupClaimType = [Microsoft.IdentityModel.Claims.ClaimTypes]::GroupSid

#Update the SPTrustedIdenityTokenIssuer object to apply the change
$issuer.Update()

There is another way….

Custom claim providers can be developed to augment claims. This can be used instead of completing the steps above. The link below will get you started on that path of development.

https://docs.microsoft.com/en-us/sharepoint/dev/general-development/how-to-create-a-claims-provider-in-sharepoint