This is a topic that becomes very important in SharePoint 2013, and that is making sure you have a fully populated user profile application. In SharePoint 2013 the user profile system plays a critical role in the OAuth infrastructure, which is what allows certain trusted application scenarios to succeed by allowing other applications to act on behalf of a user. In order for an application to be able to “know” what a user can do though, it needs to capture the list of attributes for that user so proper security trimming rules can be applied. That’s the 100,000 foot level view of this, I will write more about user profiles, synchronization and the impact on different authentication choices in a later blog.
For now it’s enough to know that it’s very important and needs to be done. Given this importance, and the fact that Bryan Porter’s seminal posting on this from SharePoint 2010 has disappeared since he moved his blog over, I decided it would be worth covering again. The good news is that it isn’t super complicated if you are importing from Active Directory, which is what this post will cover.
The first thing you should do is create your SPTrustedIdentityTokenIssuer; that is required before you can configure the profile import aspect of things. Once that’s done open your browser and navigate to your UPA management page. Click on the Configure Synchronization Connections link, and then click the link to Create A New Connection. The only thing that’s different here compared to any other profile connection to AD is the Authentication Provider Type drop down. In that drop down you want to select Trusted Claims Provider Authentication. When you do, the Authentication Provider Instance drop down below that will populate a list of all the SPTrustedIdentityTokenProviders you have created. Just select the one that should be used with this profile connection, and fill out all of the other connection properties as you normally would for importing from AD and save it. Here’s a screenshot of what mine looks like:
Once that’s done the next thing you need to do is update the property mappings so SharePoint knows what field you are importing, contains the value that users will use as the identity claim. To do that go back to the UPA management page and click on the Manage User Properties link. Scroll down and find the Claim User Identifier property and Edit it. If there is an existing Property Mapping for Synchronization value, delete it. Add a new one that maps the property you are importing from AD as the identity claim value. In my case, I’m using email address as the identity claim, and in AD the user’s email address is stored in the AD attribute called “mail”. So I just select the profile connection I created above, I type in “mail” in the Attribute edit box and click the Add button. It looks like this:
After I’m done this is what it looks like:
The Claim Provider Identifier and Claim Provider Type are supposed to be set automatically when you configure the profile import connection.
That’s it – now I can do profile imports and it will automatically map that identity claim value to the account name property in the profile system. Here’s an example of what it looks like after I’ve run a profile import. Note that instead of using domain\user for the account name, it is showing a SAML claims format with email address for the account name:
Hi Steve, I remeber that there was a blog for the same in SP2010 - can we have the link to that blog pls
don't take advantege of my bf! (bf=boyfriend) so i only asked that so steve baby can we have whatever she just asked!so back off you dumb ***! *crying sound* you made me cry so i am telling my bf (bf=boyfriend) on you for making me cry. if you want to work this out let's screen fight...that's is where we type bad things about each other back in and forther!
this girl keeps being mean to me...can you get her for me!Love you baby thank for helping me honey-baby!
Does this work with the built-in Claims provider with Windows auth? I tried it on 2013 Preview, did not work...
I am facing the same problem now - I had done the mapping, but the user profiles get dublicated...
The identifier claim is mapped, the provider property is correctly set...
What else should I map from the 'trusted identity' sync connection?
I've noticed, that many other properties get mapped automaticly to sync connection, can they be the reason for the dublicated accounts?
Having the same issue asTsvetelin, profiles get duplicated. Any ideas?
Thank you for your time...
On several places, it is clearly stated, that the users, who logs in through SAML must be different than the users, who logs in with Windows. Otherwise, they will be duplicated. Our case is that we need to give the same users two ways of logging in - in the intranet, the must log in with Windows authentication, from the internet, they must log in through ADFS. The "official" way of doing this is to use TMG. But we don't want to setup TMG, so If there is another way of mapping claims and SAML authentication to the same user, I will be very, very thankfull if someone shares it! :-)
I am curious about something. I was hoping you could help. We are importing users from Active Directory and also have extended the web app and using ADFS for a small set of users. These users are appearing in my User profile service app. I haven't set anything up to import these users and they are causing lots of confusion. How can I remove them and keep them out of the user profile service app? Is there a way?
Kathy, have you got any solution for the issue which you reported above?
Great post Steve. I have a question on this topic. What is my SharePoint connects to a trusted identity provider to which I do not have access? How can I populate a user profile for user coming from that Identity provider?Thank you
This works great but I can't get Employee Photos stored in AD (ThumbNailPhoto) to sync up with the accounts. However the images do show up in
https://my.domain.com/User Photos/Profile Pictures/ but with guids instead of account names.