Trusted Identity Providers & User Profile Synchronization

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!

Comments

• Anonymous
  July 19, 2010
  nice post
• Anonymous
  April 20, 2011
  Thanks for sharing this entry; it is not always that easy to discover hidden details within SP2010. In case we had to write a custom connector due to some reason, how could we assign values to the Claim User Identifier, Claim Provider Identifier fields in a profile? These fields are not editable. Is there a work-around for this?
• Anonymous
  May 25, 2011
  This is great info, but doesn't appear to address the more common scenario where I am using ADFS for EXTERNAL AD providers.  So if my local AD is contoso.com but I am federated with wingtiptoys.com, is there a way to import user claims info for the users from wingtiptoys?
• Anonymous
  May 25, 2011
  Mario - There is no way, using OOB synchronization, unless you have access to query the federated partners directory service (and assuming that directory service is one of the standard directory servers we support synchronization with). If you could address their AD instance, for example, you'd be good to go with the above.Otherwise, your challenge becomes synchronization of that external directory information. You could have the partner send you an LDIF file on a regular basis, or hand-craft some other custom process.
• Anonymous
  October 31, 2011
  The comment has been removed
• Anonymous
  October 31, 2011
  @Glenn,Nope. FIM requires a domain trust to synch from an AD - and not only is a trust required, it must be a two-way trust, IIRC.Bryan==
• Anonymous
  November 14, 2011
  Is it possible to implement your own synchronization source (I'm thinking AD LDS here) and bind the SPS-ClaimID behind the scenes?