Mapping User Profiles for SAML Users with an AD Import in SharePoint 2013

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:

19 thoughts on “Mapping User Profiles for SAML Users with an AD Import in SharePoint 2013

  1. Thank you so much for posting this. This is one of those really poorly documented settings in SharePoint, and even though I’ve been working with claims for years now, I didn’t realize you could do this until recently. Just basically map SPS-ClaimID to whatever attribute in AD like samaccountname, and SharePoint will auto-magically decorate the AccountName in the profile with the correct claim prefix.

    It took me forever to figure out that this was missing, and it sucks that if you don’t create the AD Sync Connection to corrected use claims / FBA in the first place, you’ll probably have to delete and recreate it. Try that for 1,000,000+ profiles!

    Normally, when we connect Beowulf as a trusted provider to SharePoint, we had to have a special claim provider that can talk directly to LDAP, otherwise the user experience for the People Picker is just godawful. but LDAP can be slow to search for users. Being able to crawl user profiles tied to AD accounts is must faster and works much better than going back to AD for this info.

    You made my life better. I owe you a beer, SamlMan!

    Liked by 1 person

    • Hello Steve, Thomas. Do you mean that having profiles synchronized this way will set us free from using claim provider? I have an issue with using ADFS and when users try to enter name in people picker, it does not work, it just returns the same string as user typed in.

      Like

      • That’s because nothing provides validation of your input string. You should definitely use specific claims provider, take a look at the LDAPCP on CodePlex. Configurable and powerful.

        Like

  2. Hey Samlman!! Thanks for your posts, I really appreciate them 🙂

    I want to discuss withyou about an issue that we are facing in a ADFS deployment with SharePoint. To give you a situation: Currently all is working well, except for the Workflow manager for certain users, let me illustrate this:

    We have several domains, but all the ADFS users comes from a particular domain, in this case we have configured succesfully the UPA as it shown in your post as well the ADFS, where we have configured the UPN as claimidentifier.

    But in the UPA, some user there are appearing with two accounts (only a few of 16k), one user with the claim of ADFS (it is correct) and the other one with format “domain\user”. Also, after digging, we realized that this users that appears twice in the UPA, are the users that are having problems to execute the WF, because in our case we are using the currentStateUser variable.

    We’re thinking in deploy a kind of PS script to delete programatically the profiles that comes from “domain\user” to not to affect to the behaviour of the platform, but I don’t really like this idea. Do you have any clue about what is happening? Could be the job to mix the information from profiles?

    thanks!!

    Like

    • Hey albandrod, is there any chance that you have or at one time had Windows authentication configured for your web applications as well? That is the most common reason that you end up with multiple UPA accounts for the same person (if I read your summary correctly). If you support both forms of auth then the same person is actually two different people to SharePoint and the UPA because each logon = one person to SharePoint.

      Like

      • That’s funny, I was going to say more or less the same thing. If you have a classic windows – or even claims windows user – and they have the same username as an FBA or even trusted provider account, such as when FBA or ADFS talks to LDAP/Active Directory – then its not uncommon to see two profiles pop up in the people picker, UPA, or other places because as Steve says, these are separate identities.

        It may be fine to delete the legacy profiles if they aren’t in use anyplace. But many systems have dual providers on purpose and for good reason, like as a backup in case the IDP goes down, or to let users inside the firewall operate with Windows integrated auth. Under those circumstances I would encourage you to tread lightly.

        Like

  3. Thanks for yours answers! I understand what you’re saying and it has all the logical, but there is something in the middle that I’m losing

    We have the default zone in NTLM authentication for crawling purposes and then an Extended Web Application in the Intranet zone to use ADFS, Is it true that, first time we extended the web app, there were 2 authentications methods at the same time as both of you exposed, so could be the source of the problem.
    But currently only ADFS authentication method is available and most of these users had never log in the NTLM zone, always in the ADFS zone, for this reason I’m very surprised.

    I will try to delete the profiles that are not ADFS from the UPA, and see if they are recreated again or what. I will keep you updated 😉

    Like

    • Often, people will leave an extended zone with Windows Auth on the web application just so that search service will correctly crawl content. You’ll see warnings if you disable the NTLM/Kerberos option in Authentication Providers. It’s not uncommon to leave it around also as a backup, because multi-server based federated authentication can be quite fickle. Who wants to be 100% locked out of SharePoint due to expired certificate in ADFS, lol?

      That being said, yes, I think if your old profiles are truly vestigal, they can be safely removed. There are only a couple ways they would be recreated. That would be if there’s an ADSync connection that is not set up with the properly trusted/FBA provider and SPS-ClaimID property (as above blog shows how), or if the user directly clicks the link to go to their profile/mySite. I believe even in the case of a search crawling account, that just authenticating to the SharePoint site itself is not enough to make it create a profile for that user – but perhaps as SAML-man says in 2013 there are more hooks into UPA, so my info here might be old-thinking from 2010 era.

      For most cases, such as the people picker, you can avoid having duplicates by disabling auth providers which are not in use. Sounds like if you did an extended web app/zone, that you have already hit on this to a degree.

      To me, the bigger picture problem is what to do about situations where you actually want dual authentication. This problem, particularly in workflow, is a thorny one in those situations. Anything that relies on the profile service to resolve users or FillResolve/FillSearch methods of the claim provider model could potentially hit this limitation. Ahh, well, I guess I have yet another reason to steer clear of SharePoint OOTB workflow wherever I possibly can! ^_^

      Like

  4. Hi Steve, How are you Sir? Its as usual a great thing to read about your Posts which are the best when it comes to SAML and SharePoint. I do miss bothering you as I used to earlier :). Hey I have a quick doubt and thought of running it by you, how do we configure the USer Profile Sync when we have the user’s in Azure AD. So we setup users in Azure AD (manual/dir-syn from on prem AD) now how do we configure the User Profile Sync connection to the On-Prem SP 2013 (or Azure IAAS SP 2013 VM) so that the profiles are sync’ed from the Azure AD. I did read about the way to configure authentication that you had posted long time back thru ACS but was trying to understand how to sync Profiles from Azure AD. Any help? Thank you!

    Like

    • Mr. Ketan, very long time no talk. 🙂 The short answer is that there isn’t a way out of the box to sync users from Azure AD into the UPA, sorry. Could definitely be developed, but I’ve never done it. Quite possible someone else has though. It honestly would not be that hard, as long as you don’t try and do incrementals. Even incrementals may be possible, not sure, but full imports would be pretty easy I think.

      Like

  5. Hi Speschka,

    I need your help. I have a sp2010 site. It has AD users since beginning having their permissions and content. I implemented saml authentication but the same users are treated as new “trusted” users. Is it possible that all their personal views, list or libraries accessible in same way as before but authenticated by cba. kindly help me.

    Like

    • Hi David, they are completely different users to SharePoint. You need to migrate the Windows accounts to SAML accounts. You can search my blog for imigrateusercallback to find some code examples and a sample tool.

      Like

      • Hi Speschka,

        Thank you so much for your reply. I got the tool you developed. I tried to use it but I get an error while doing the migration. I would be thankful if you could help me to understand why this error could be. Any help/suggestion highly appreciated. Thanks in advance. Error popup message:

        “An error occurred during the migration. You can try and resolve the error and try again. The error message was: Value doesn’t fall within the expected range.”

        Like

      • Hi David, I would expect to have to step through a debugger to get the error message. I thought the latest code I posted up there included the source, but if not let me know and give me a link to the specific post you pulled it from.

        Like

  6. Hi Speschka,

    Thank you so much for your tool.Its a great tool. I understood what was the problem and why it was not working earlier. Actually i have two web applications which use the same Trusted Identity provider. When i removed the realm of second web application from Trusted identity provider, i was able to migrate users from windows claim to saml claim. Great tool, great articles. Thank you so much again.

    Like

  7. Hi guys,

    I have the “usual problem” in the UserProfile sync.
    My users appear twice in the UP, for example: domain\johndoe and iw05:etc.etc.|johndoe@domain.com

    My webapp have Windows Authentication (because of search, but we can extend the web app like u said) and a Trusted Provider.
    And my UP have 2 connecions, one connection to the “normal” AD and another one to the Trusted Provider (ADFS).
    The user profile properties have two mappings, one for each connection.

    My question is:
    – What is the cause of the repeated users, the 2 authentication providers OR the 2 connections in the UP?
    – I read somewhere that the connection to the “normal AD” is required with ADFS. Is this true?

    thank u so much for your support.

    Like

Leave a comment