Recently, a few people have been trying to figure out how to get user profile synchronization working when doing claims authentication via a trusted identity provider, as is the case in many federation scenarios involving ADFS, for instance. I’ve heard of people writing one-off jobs that iterate over their profile store updating the Account Name attribute to gets things to match up properly; luckily this isn’t required, as SharePoint profile sychronization already has support for doing this for you during profile imports. It just take a wee bit of configuration to get working.
It’s not obvious, but there are some hints in the user interface regarding how to make this kind of configuration work. Namely, when configuring a directory synchronization connection, you can specify the type of authentication provider that’ll be used to access the imported profiles, and in the case of a trusted claims provider, you can even select the specific trusted provider configured in the farm.
Unfortunately, if you stopped here – and most people do – you’ll be dissapointed to fine that while your profile imports succeeds just fine, when you log in as a user via the trusted claims provider you specified your login won’t be associated to its corresponding profile in the user profile store. What gives?
Well, it turns out that in order to give the user profile system enough information to map your imported profiles to incoming authetnicated users, you have to tell it what imported attribute is going to correspond to the authenticated users identity claim. Remember, when you configured your trusted identity provider, you specified a claim as the identity claim – this claim is immutable, you can’t change it once you’ve configured the trusted identity provider. In order to map users properly, you have to tell the user profile system which of the innumerable attributes it may be importing is going to be used as the identity claim. Once you give the profile system that information, it’ll have enough information to calculate what the identity claim of the profile will be when someone logs in for it.
So, what property do we need to map? Well, obviously enough, it’s the Claim User Identifier property.
In the screenshot above, you’ll notice that I’ve got my property mapped to the mail incoming attribute. This is just the claim I chose to use in my setup – you can use whatever you’d like, but remember it’ll need to be the attribute that’s being presented as the identity claim from the trusted identity provider.
Once this is in place, firing off a user profile import will result in your users suddenly getting associated to the correct profile. Yay!
Hope this helps anyone out there who’s been struggling with getting this working!