SharePoint 2013 User Profile Sync for Claims Users

Artigo
05/23/2013

I have been working with claims authentication quite a bit lately, and something that can be frustrating when using claims authentication for Forms Based Authentication (FBA) or SAML claims is that when you log in you see the claims identifier instead of the user’s name. As an example, I configured an FBA provider to use LDAP to authenticate users and when I log in, I see the following:

Similarly, I configured a trusted provider using ADFS and when I log in as a user using SAML claims, the user’s name is shown as the following:

This is because the user profile for the user has not been populated. In my environment, I have 3 providers configured for the same zone.

To understand how to configure the trusted identity provider, see Steve Peschka’s post Configuring SharePoint 2010 and ADFS v2 End to End. To understand how to configure FBA, see my posts SQL Server Provider for FBA in SharePoint 2010, configuring FBA with SqlMembershipProvider in SharePoint 2010 using PowerShell, and Configuring LDAP for FBA in SharePoint 2010 or SharePoint 2013 with PowerShell.

This post is going to show how to configure user profile synchronization when you have multiple authentication providers. In my scenario, all of the users are being imported from the same Active Directory instance. This provides a challenge for using apps. Working with apps in SharePoint 2013 requires user profiles to be populated (see Steve Peschka’s article, “OAuth and the Rehydrated User in SharePoint 2013 – How’d They do That and What do I Need to Know”). It becomes increasingly important in SharePoint 2013 to properly configure the user profiles with UPN, Email, or SIP attributes when working with apps. It doesn’t matter how you populate these, you could use PowerShell or a custom program, but SharePoint provides the ability to populate these attributes using User Profile Synchronization. The challenge is that apps will rehydrate the user typically based on email, so the email has to be unique across all of the user profiles. This makes it important to make sure that each user in your directory has exactly one profile in SharePoint.

Steve Peschka did a great job showing how to accomplish this in his blog Mapping User Profiles for SAML Users with an AD Import in SharePoint 2013. The part I want to highlight is how to configure multiple sync connections.

Multiple Synchronization Connections

In my scenario, I have 3 different connections to the same Active Directory.

The challenge here is making sure that your users do not overlap and that they are unique per connection. If you have a user that is imported from AD and authenticates both as a Windows user and as a SAML user, the authentication for apps will likely fail because you cannot uniquely identify the user based on email. This is why it is important to make sure that each user account has a unique profile.

Configuring Multiple Connections for User Profile Synchronization

I am not going into the details of how to start the user profile synchronization service instance. For details, see Spence Harbar’s seminal post Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization. The steps are identical for SharePoint 2013. The part we are going to focus on is configuring the connections for our scenario that includes multiple connection sources.

Configuring a Connection for Active Directory

This is the best-documented and easiest to configure because you only need to configure the connection and you’re done. Spence covers the details in his blog post Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization. Even though we are authenticating with Windows claims, the only thing you need to do is configure user profile synchronization to Active Directory.

The important thing to watch out for is that you import only the users who will log in via Windows. I have an OU called “Employees” in Active Directory that contains all of my users who authenticate via Windows to avoid overlap.

When configuring the user profile synchronization connection, I choose only this OU.

Click OK and you’re done.

Configuring a Connection for FBA

My FBA implementation is using LDAP, which points to Active Directory to authenticate the users. Because I am using Active Directory as the LDAP provider for FBA, I can import the users with a connection to Active Directory with one special change. The key is to set the Authentication Provider Type to Forms Based Authentication, and choose the FBA provider that you’ve already configured (this value is picked up from the web.config in Central Administration).

To make sure that the account does not have multiple profiles, I constrain the synchronization to a specific OU that contains only those users who authenticate via LDAP.

Once you have configured the connection, the next step is to map the claim identifier. Go to the User Profile Service Application and click on User Profile Properties. Edit the property “Claim User Identifier” and add a mapping for the attribute that will be used to identify the user via claims.

Setting the authentication provider type, selecting the FBA provider, and mapping the claim identifier is important because this is used to map the claims encoded account name. Once the user is imported, you can see the claims encoded account name to identify the user.

If you see two profiles for the same user, the problem might be because you didn’t map the provider type on the connection, or didn’t add the mapping for the claims identifier.

Configuring a Connection for a Trusted Identity Provider

I am using ADFS to authenticate my users. When I use user profile sync, I am not connecting to ADFS, I am connecting to the Active Directory where the users are authenticated to. I can sync the users to that Active Directory to populate their attributes. As mentioned several times earlier, I need to make sure that the user profiles are unique. To ensure this, I have a single OU for the users who authenticate via ADFS.

I then set up a user profile sync connection to Active Directory. Just like when we configured FBA, we need to specify the Authentication Provider Type (this time we choose “Trusted Claims Provider Authentication”), and the Authentication Provider Instance (which is the name of the trusted identity provider you’ve already configured).

To make sure that these users do not have multiple profiles, I import them from an OU where only those users authenticate via ADFS.

The next step is to go to the user profile properties and add a mapping for the Claim User Identifier. Note that when you have multiple connections, you will need to map each individually. I could have the FBA users mapped using sAMAccountName instead of mail, I just chose to map them using the mail attribute since all my users have an email address. Edit the property Claim User Identifier and add a mapping.

The claim identifier that you map for the ADFS connection needs to be the same attribute that you specified in the IdentifierClaim parameter when registering the SPTrustedIdentityTokenIssuer.

 $ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" 
    -Description "SharePoint secured by SAML" 
    -realm $realm 
    -ImportTrustCertificate $cert 
    -ClaimsMappings $map,$map2 
    -SignInUrl "https://congen1.contoso.local/adfs/ls" 
    -IdentifierClaim "https://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"

See Steve Peschka’s blog Configuring SharePoint 2010 and ADFS v2 End to End for more information on configuring ADFS.

One other side note… when you are adding users to your site that are SAML users, take care to use the same identifierclaim when adding them as a user to a site. I type the full email, and then make sure I select the EmailAddress claim. If you want to change this behavior, see Steve Peschka’s blog for creating custom claims providers. The user will show as the IdentifierClaim until the user profile is updated with their name.

What if My User Doesn’t Come From Active Directory?

FBA users are a little more difficult because you may be using SQL for FBA, in which case there’s really no option for user profile synchronization out of the box, you need to update it through some other means. Additionally, you might be authenticating to a trusted provider where you cannot sync all the users from the source into user profiles. Luckily it’s pretty easy to update via using the object model, which can be accessed via PowerShell or C#.

 $mySiteUrl = "https://my.contoso.lab"

$gc = Start-SPAssignment 

$site = ($gc | Get-SPSite $mySiteUrl)
$context = ($gc | Get-SPServiceContext -Site $site)
$upm = new-object Microsoft.Office.Server.UserProfiles.UserProfileManager($context)
$profile = $upm.GetUserProfile("i:0#.f|ldapmember|barneyrubble@contoso.lab");
$profile["WorkEmail"].Value = "barneyrubble@live.com";
$profile.Commit()

Stop-SPAssignment $gc

Other properties that you might want to map are SIP (mapped to the SharePoint property “SPS-SipAddress”) or the UPN (mapped to the SharePoint property “SPS-UserPrincipalName”). The important point to note here is that it doesn’t matter if you use user profile sync or if you populate the attributes through some other process, the part that matters is that the properties are populated for the user. You could also provide the user’s name while you’re at it to provide a friendly name at the top right of the screen.

Showing The User Name

This blog started off showing the problem of claims users not showing their name in the top right of the page when they log in. The only thing you have to do is make sure that their name is populated in the user profile, either through sync or through your own process. To prove this, the same user that used to show the email now shows their name instead.

The name is displayed as part of their user profile, so you can take advantage of the fact that apps require a populated user profile and simply populate the name as part of your sync process.

For More Information

Configuring SharePoint 2010 and ADFS v2 End to End

Configuring LDAP for FBA in SharePoint 2010 or SharePoint 2013 with PowerShell

configuring FBA with SqlMembershipProvider in SharePoint 2010 using PowerShell

Rational Guide to implementing SharePoint Server 2010 User Profile Synchronization

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

Comments

Anonymous
May 23, 2013
This post has a potential of becoming THE canonical post on user profile sync in SharePoint, thanks!
Anonymous
May 26, 2013
Great post!
Anonymous
June 06, 2013
Great article!Can I just synchronize user profiles from trusted external Active Directory ? I've heard of that it's not possible.Regards,-T.s
Anonymous
June 06, 2013
Thuan - you'll need to configure a connection to the directory server where you want to import profiles from and import directly from that directory server.
Anonymous
April 01, 2014
Hi, I've configured a FBA with a Database and now I can find the users, but I cannot mention the user. Do you have any idea about how to solve it?Another problem happen when I try to access to the profile. I think that this is because the Claims name is not encoded.Thanks!Carlos
Anonymous
April 02, 2014
The comment has been removed
Anonymous
May 01, 2014
Hi KrikCan we merge both two profiles into one, example if we import saml users and ad users can we merge both users so that profile properties values would be same?
Anonymous
May 01, 2014
Sandeep - they are two distinct and different users with two distinct and different user profiles. There is no merge capability. You could always write custom code to update the profile properties yourself. See the http://OfficeAMS.CodePlex.com project for an example of updating user profiles using the cloud app model.
Anonymous
June 09, 2014
We are using claims, eg:i:0k.|my provider|usernameWe have no access to the trusted identity provider's LDAP or database.1) Can we just add a new user profile for i:0k.|my providerusername ?2) Does the space in the trusted identity provider "my provider" present a problem?
Anonymous
June 09, 2014
The comment has been removed
Anonymous
June 09, 2014
The comment has been removed
Anonymous
June 09, 2014
Thanks Kirk. After I asked this question, I thought about using an LDAP filter, available in the OOTB connection to constrain which users I pull from the gigantic "Accounts" OU. Keeping my fingers crossed that it will get me to where I need to go.Thanks again for a really helpful blog!-Tim
Anonymous
July 20, 2014
Hello there, I have a web application that has 2 zones (NTLM & FBA LdapMembershipProvider). When I assign a task in a workflow (SharePoint Designer), in windows mode, it works normally, but in FBA mode, I have an exception: UserProfileException .. Exception caught Microsoft.Office.Server.Security.UserProfileNoUserFoundException: 3001002; reason = The incoming identity is not mapped to-any user profile in SharePoint account. Is That Possible causes no user profiles are created in user profile database. Contact your administrator. at Microsoft.Office.Server.Security.UserProfileIdentityClaimMapper.GetSingleUserProfileFromClaimsList(UserProfileManager upManager, IEnumerable `1 identityClaims) at Microsoft.Office.Server.Security.UserProfileIdentityClaimMapper.<>c__DisplayClass2.<GetMappedIdentityClaim>b__0() is thrown.
Anonymous
August 06, 2014
Is there a reason why the Claim Provider Identifier and Claim Provider Type would need mappings to both AD and ADFS? The Claim User Identifier only uses ADFS. I started with a fresh User Profile SA. After adding the additional import connection for ADFS and adding the mapping for Claim User Identifier, I kicked off a full import. it created duplicate profiles for each user. One has the domain format in AccountName and one with the claims format. The only thing I can see that might cause this is the duplicate mappings in Provider Identifier and Provider Type.
Anonymous
August 19, 2014
I did exactly as you instructed for the FBA with ldap query. While user profiles in the UPA populates Preferred name with the meaningful display name, nothing gets reflected in the site collection. Users still showup with thier user id instead of display name. I ran sync from ad too just to be sure but yet no difference?Any idea,
Anonymous
October 22, 2014
Hi KirkI have the same issue with Sandeep.and I have been posted to the following URL similar issue.social.msdn.microsoft.com/.../how-to-make-windows-claims-and-saml-claims-recognize-as-same-identity-Is this a product specification?The solution to this issue ,Either would be feasible on the basis of the samples in the?http://OfficeAMS.CodePlex.comOffice App Model Samples - July 2014 - Update 1There are a large number of samples to,"Updating user profiles using the cloud app model"I was looking for something to be true, but it was not found.Is This Mean "Core.BulkUserProfileUpdater"?Regards,Kazuo Tsukiyama
Anonymous
November 07, 2014
I gave up the SAML authentication in SharePoint.SharePoint authentication provider, and the only Windows authentication (Kerberos), was resolved by configuring the ADFS pre-authentication by the WAP.technet.microsoft.com/.../dn528827.aspx www.brightstarr.com/.../securely-publishing-sharepoint-externally-using-web-application-proxy-part-2SAML authentication It is better to be simplistic and shall be available for users outside the organization.It requires a flexible mindset.(^^;)Regards,Kazuo Tsukiyama
Anonymous
December 04, 2014
I am surprised you can't "Join" the ADFS profile feed with the AD profile feed considering the backend of the profile service is FFIM. If you ever used just FFIM you would just use a unique identifier to join the two accounts feeds. This could be the email address.I am planning to use ADFS auth for all users. If that's the case, do I even need the Domain profile feed anymore or is it needed for the Application Service accounts to work correctly?
Anonymous
March 18, 2015
I have an issue with a farm which having both WIndows (NTLM) and ADFS authentication. When we try to publish a simple work flow, it works with the NTLM web app but when same simple workflow published on ADFS enable web app it failed. with the STS errorSTS Call Claims Saml: Problem getting output claims identity. Exception: 'Microsoft.Office.Server.Security.UserProfileIdentityClaimsMappedToMultipleUsersException: 3001003;reason=The incoming identity is mapped to more than one user profile account in SharePoint. Possible cause is that there are duplicate or obsolete entries in the user profile database. Contact your administrator
Anonymous
March 18, 2015
@Waqas - yes, and that was the reason that I mentioned repeatedly that the profiles must be unique. The email, SIP, and UPN must be unique across all user profiles. You cannot have two user profiles with the same email or two user profiles with the same UPN or two profiles with the same SIP else you receive that error. This will happen if you have imported the same user object twice. This article took great care to ensure that did not happen and reinforced the importance of uniqueness.
Anonymous
April 06, 2015
Hi Kirk,Thanks for great blogging!!!! I "only" have one problem, we are using Shibboleth as an Idp and we are have created a proxy "downgrading" from SAML 2.0 to SAML 1.1. So NO ADFS or anything. My problem right now is I can't SET the 'SPS-UserPrincipalName' in the UserProfile since it seems to be read only.... Do you have any workarounds for this or am I doing something wrong?[8796] 2015-04-07 07:36:33,615 ERROR UserProvisioning - Error updating UserProfile property [SPS-UserPrincipalName] = [_3366@ByggnadsForbund] [Microsoft.Office.Server.UserProfiles.PropertyNotEditableException: Property Not Editable: This property can not be modified.Thanks in advance!Jonas
Anonymous
June 03, 2015
What if same user logs in using both windows authentication as well as ADFS. In that case do we need to have the users copied in two separate OUs in AD one for windows and one for SAML?
Anonymous
June 15, 2015
Hello Kirk Using PingFed for authentication. Just added a new property to the sync ("Office Location") and ran a full sync. Within hours, users were having issues accessing sites. It looks as if their PingFed accounts had been deleted, and AD accounts had been updated with the newly requested property ("Office Location"). Any thoughts on the cause of this?
Anonymous
June 26, 2016
Nice blog right here! Additionally your site so much up very fast!What web host are you the use of? Can I am getting your affiliate link to your host? I desire my web site loaded up as quickly as yours lol

Compartilhar via