SharePoint: Active Directory Import with Trusted Provider authentication: Map only Claim User Identifier

Posted On June 5, 2019

 

Summary: You do this a bit differently than when using FIM Sync.

When using Active Directory Import (AD Import) with SharePoint 2013, 2016, 2019, etc, only the “Claim User Identifier” (SPS-ClaimID) profile property needs to be mapped manually. 

“Claim Provider Identifier” (SPS-ClaimProviderID) and “Claim Provider Type” (SPS-ClaimProviderType) are mapped automatically when you create the import connection. Trying to map those properties manually will result in all user profiles being imported as Windows Authentication-type profiles instead of Trusted Provider-type profiles.

 

Details:

First, some background:

In SharePoint 2013, you have three choices for importing user profiles into SharePoint:

Use SharePoint Profile Synchronization — This uses a built-in version of Forefront Identity Manager. I refer to it as “FIM Sync”

Use SharePoint Active Directory Import — This uses a timer job to import profiles, known as “AD Import” or “ADI”.

Enable External Identity Manager — This allows you to use an external product to Sync profiles like Microsoft Identity Manager (MIM).

In SharePoint 2016 and above, FIM Sync is gone so you just have AD Import and External Identity Manager.

 

Creating the AD Import Connection properly:

When using a Trusted Provider (AKA: SAML / WS-FED authentication), in order to import user profiles in the proper claims notation, you need to map the “Claim User Identifier” (SPS-ClaimID) property to whatever property you’re using as your Identity Claim.

Verify your Identity Claim.

If you’re not sure what you’re using for your Identity Claim, you can run this PowerShell:

$ti = Get-SPTrustedIdentityTokenIssuer ADFS

$ti.IdentityClaimTypeInformation

 

In my case, I’m using UPN:

 

Now you’re ready to create the Import connection in the UPA

You set the “Authentication Provider Type” as “Trusted Claims Provider Authentication”, and then choose the instance.

The rest is the same as when using Windows auth, pick your containers and hit ok to create the connection.

 

Now we need to create the mapping for “Claim User Identifier”

Go to Central Admin | Your UPA | Manage User Properties.

By default, right after you create the import connection “Claim User Identifier” will be mapped to samAccountName.

If that’s not what you’re using as your Identity Claim (I’m using UPN), that needs to change.

 

Edit the property mapping and remove the mapping to samAccountName

Then add your own mapping to the AD Attribute you’re using for your Identity claim.

The trick here is that you need to map it to the actual Active Directory attribute name, not the claim name.

For example, I found that my Identity Claim was “UPN”, but the backing AD Attribute is actually called “userPrincipalName”.

In that case, I need to create the mapping to “userPrincipalName”.

Likewise for those of you using email address as your Identity Claim, you would want to map “Claim User Identifier” to the “mail” AD Attribute.

Here’s where AD Import is different from FIM Sync

With AD Import, the “Claim Provider Identifier” and “Claim Provider Type” are automatically mapped. You should not manually create mappings for them.

This can seem a bit misleading since it doesn’t show any actual mappings for them in the UI:

This is another situation where, when using AD Import, the UI does not show property mappings, but they do actually exist. For more info see my previous blog post:

SharePoint: AD Import Profile Property Mappings aka: my profiles are missing email address

 

To be sure, you could check the ADImportConstantPropertyMapping table in the Profile database. If you join with the PropertyList table, you can see the property names and their values.

 

 

This is the important part:

I mentioned this in the summary above, but I’ll provide more details here.

If you manually create mappings for “Claim Provider Identifier” and “Claim Provider Type”, it will cause the Import connection to flip back to “Windows Authentication” for the “Authentication Provider Type”, and all of your user profiles will be imported as Windows-auth profiles instead of Trusted Provider Profiles.

For example, if I manually make mappings like this:

It causes the Sync connection to revert to Windows auth like this:

And all of my profiles will be imported as Windows Auth profiles like this:

 

In contrast, this is what my profile should look like when imported as at Trusted Provider-auth user, using the UPN Identity Claim:

 

We’ve seen this type of problem in cases where customers are using a PowerShell Script to set the property mappings.

To be clear, using a PowerShell script to set property mappings is a good idea. It makes things easy and repeatable.

However, if you’re attempting to use the same script that you previously used with FIM Sync, and are mapping “Claim Provider Identifier” and “Claim Provider Type” with the script, that is a problem. With AD Import, you don’t manually map those two properties.