Trusted Identity Providers & User Profile Synchronization

Trusted Identity Providers & User Profile Synchronization

Rate This
  • Comments 7

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!

Leave a Comment
  • Please add 3 and 2 and type the answer here:
  • Post
  • nice post

  • 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?

  • 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?

  • 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.

  • Nice article, This helped alot, I do have a issue with the setup in our enviorment. Well not so much with this setup but a general question on the sync with a externla domain...

    I have set this all up, we have a external domain we want to sync profiles with but have notrust.

    The sharepoint farm is in one Domain (Domain ABC) and the user profile sync works just fine.

    There is a second Doamin, that we want to import users from (Domanin XYZ).

    We have NO trust between the Domains. But, we are using ADFS and a trustedclaimsprovider which allows users form the XYZ Domain log on to sharepoint.

    I can run the sync with the XYZ when I setup the connection, but the next day when it runs as per the schedualed sync,  the connection to the XYZ Domain fails.

    I have found that if I edit the connection by putting the password back in and reselecting the OU's the connection will work for that day ( I need to do a full as it says the connetion has changed since the last incremental ) and then again it fails the next day with the same error.

    The servers Aplication event error logs show  FIMSynchronizationService erro event ID 6000 "The management agent "XYZ EXTERNAL" failed to run because the credentials were invalid"

    The MMIISCLIENT.EXE shows that the Sync witht e XYZ domain cannot be doen due a to: failed-authentication

    So it appears that the FIM service account cannot connect to the XYZ external domain, which I am assuming is due to the lack of the trust.

    How do I get around the FIM account requireing a TRUST?

    Is this Possible?

  • @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

    ==

  • Is it possible to implement your own synchronization source (I'm thinking AD LDS here) and bind the SPS-ClaimID behind the scenes?

Page 1 of 1 (7 items)