Few years ago, almost all companies were using their SharePoint environment authenticated directly with AD. Most of those were configured simply to use NTLM authentication. That provided easy SSO for domain joined machines and users accessing from within the company network. Following microsoft guidelines, many companies made use of Active Directory (AD) security groups to provide permissions to a large set of users.
Problem Statement
With Office 365 and other cloud services, many of those companies started making use of Federated Authentication like Active Directory Federation Service (ADFS) to ensure all cloud services use the same credentials and provide SSO.
We did exactly the same for one of our customers following this technet article to configure ADFS with SharePoint 2016. After sometime, we received complaints from some site administrators that they couldn’t use the AD Security Groups anymore, as SharePoint people picker wouldn’t resolve them.
Investigation
Obviously, this was not what we were expecting. So, we started to look into the details. First point that came up was that technet article only mentions to map the Email Address and UPN in the ADFS claim rules. It doesn’t include anything which can understand AD groups as such.
Now, that gave us some idea about what to look for. We went back to ADFS and checked which claims were configured there and we found same story.
and also in SharePoint, when we checked the claims being sent using Get-SPTrustedIdentityTokenIssuer PowerShell command, it was the same story
With these findings, the solution seemed simple – Just add the AD groups in the claims and it should work. Well easier said than done 🙂
Solution
So, all we had to do was to add the AD groups as claims in ADFS and then update SP Trusted Identity Token Issuer to send the same.
Update ADFS Claim Rule
So, we just updated ADFS claim rules first and added another rule – Select “Token-Groups – Unqualified Names” from under LDAP Attributes and map it to “Role” under Outgoing Claim Type.
Update Trusted Identity Token Issuer in SharePoint
This sounded easier. Just a quick google gave this microsoft article in search result and syntax looked straight forward.
[code]
Get-SPTrustedIdentityProvider -Name "ADFS Claims" | Add-SPClaimTypeMapping -IncomingClaimType "http://schemas.micsoroft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -LocalClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
[/code]
But when tried, I received this error message
It was time to look further. A little bit of more googling around gave this article.
[code]
$roleClaimMap = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” –SameAsIncoming
$trust = Get-SPTrustedIdentityTokenIssuer -Identity “ADFS20Server”
Add-SPClaimTypeMapping -Identity $roleClaimMap -TrustedIdentityTokenIssuer $trust
[/code]
Again this ended up in another error 🙁
The above error did give an idea about what could be wrong. It was apparent that Add-SPClaimTypeMapping command was expecting the claim to be already available with Trusted Issue Token Issuer.
So I splitted the command into two parts.
Final Solution
After a few hours of hit and trial, I finally ended up with this script which worked 🙂
[code]
$trust = Get-SPTrustedIdentityTokenIssuer "ADFS Claims"
$trust.ClaimTypes.Add("http://schemas.microsoft.com/ws/2008/06/identity/claims/role")
$trust.Update()
$GroupClaimType = "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"
$roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType $GroupClaimType -IncomingClaimTypeDisplayName "Role" -LocalClaimType $GroupClaimType
Add-SPClaimTypeMapping -Identity $groupClaim -TrustedIdentityTokenIssuer $trust
[/code]
After this, I could see the 3 claim types
Update LDAPCP Configuration
One last thing to add, as I was using LDAPCP which queries Active Directory servers to enhance people picker with a great search experience with ADFS authentication. So, I just configured it to show proper display name of AD groups in people picker.
Verification
Now, with all the required configurations in place, it was time to check whether SharePoint people picker started resolving AD security groups on not.
That was a nice view after few hours of head crunching.
And that was it… Happy days 🙂
Enjoy,
Anupam
