Group Augmentation

Jan 25 at 11:01 AM
Edited Jan 25 at 11:06 AM
Hi there,

Having a crash course on SAML, Sharepoint and claims to implement a solution so apologies if I've got something simple wrong.

To set the scene I have a SAML IdP providing 2FA to a Sharepoint 2016 install, this works and users get in, if I add the short form group name that my IdP sends in the People Picker then users get in ok.

Customer has a lot of AD groups setup for the normal NTLM auth so wants to reuse that config so LDAPCP seemed like the ideal solution to test, I was presuming we could use it to link the SAML claim to the proper AD groups and Sharepoint would pick that up?.

I think I have it all setup correctly, IdP uses a different claim class for CN and groups so have adjusted them, enable Augmentation and checked the logs and it seems to augment the user but still get no access to the SP site.

Just wanted to check I haven't completely misunderstood or got it wrong as have gone from 0% knowledge of all this since Monday :-)

Pics, of setup attached



Jan 26 at 3:02 PM
Hi Nic,
the configuration looks correct, but did you check how roles are formatted by the IDP?
In the screenshot roles value are "domain users" or "users", so the IDP must send them like this too. And not, for example, "domain\domain users" or "domain\users".
You may also double check that the claim type for the role is the same between the IDP and LDAPCP
Jan 26 at 4:07 PM
Hi Yvan,

Thanks for the reply, yes the IdP sends the same format value and claim type, SSO tracer shows the following in the assertion

<saml:Attribute AttributeName="Group" AttributeNamespace="">
<saml:AttributeValue>Sharepoint Users</saml:AttributeValue></saml:Attribute>

Have I got it right that using LDAPCP should map the groups over so that the User Policy that was configured for the NTLM users should still work for the SAML users?
Looking at the policy is shows the GroupSID. I also wondered if it was because I was using a different claim type and not the I see when looking at the claim details for a NTLM log in?

I am just guessing there as not completely got my head around everything


Jan 30 at 3:18 PM
Hello Nic,
So your IDP configuration matches LDAPCP config, but you cannot use the Windows groups claim types, you must migrate them to the role claim type you defined in the SPTrustedIdentityTokenIssuer object that you created
For this I recommend that you use SPFarm.MigrateUserAccount() method:
# Migrate WinClaim group to  trust "localad" with claim type
[Microsoft.SharePoint.Administration.SPFarm]::Local.MigrateUserAccount($oldlogin, $newlogin, $false);
Marked as answer by Yvand on 2/2/2017 at 4:54 AM
Jan 31 at 2:36 PM
Ahhhh ok that sort of makes sense :-) so because the claim type is 'w' for a windows claim the SAML claim doesn't apply?

If I change the role though I presume that basic Windows authenticated users won't then be able to access the site?
Jan 31 at 3:39 PM
True and true :)
if you don't want to migrate the role account (for the good reason that you mentioned), you can simply create a new one in trusted (SAML) format, through the people picker
Jan 31 at 3:49 PM
Super super, think I misunderstood the purpose of LDAPCP augmentation, was hoping that the information it populated the claim with would enable the existing Sharepoint permissions to "just" work.

It certainly makes the people picker easier to navigate though our IdP sends the group info through in the ticket anyway so if we want both AD and SAML authentication to work we really need to define two seperate rules in the picker.

On the upside I've learnt a lot about Sharepoint, SAML and claims over the last week, which is good as off to Paris tomorrow to see customer :)

Thanks for the help.
Feb 2 at 11:54 AM
You're welcome !
Feb 23 at 9:58 PM

very interesting, could you advise on how do you able to setup the claim mapping for group as it showed Green in your LDAPCP mapping table above?