Kirk Evans is a Microsoft Architect for the Azure Center of Excellence.
Introduction to SharePoint and Azure IaaS
Building SharePoint Apps with Windows Azure Platform as a Service
SharePoint Solutions and Architectures on Windows Azure Infrastructure Services
Understanding Authentication and Permissions with Apps for SharePoint and Office
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.
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.
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.
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.
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.
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"
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.
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 = "http://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:email@example.com");
$profile["WorkEmail"].Value = "firstname.lastname@example.org";
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.
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.
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
This post has a potential of becoming THE canonical post on user profile sync in SharePoint, thanks!
Can I just synchronize user profiles from trusted external Active Directory ? I've heard of that it's not possible.
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.
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.
Carlos - I am not entirely sure about your particular configuration requirements. I suggest posting to stackoverflow.com/.../sharepoint as the product team and many MVPs and community folks are watching, you have a better chance of finding someone familiar with your particular configuration challenge. Sorry I don't know the answer off the top of my head.
Can 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?
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.
We are using claims, eg:
We 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 provider\username ?
2) Does the space in the trusted identity provider "my provider" present a problem?
I have a client that has stored all their authorized SP users in a Global Group. This CN is located within a different OU than the users. In using the FBA sync, should I be pointing to the CN that has that group, or the Accounts OU where all of the organizations' users reside? My SP users are only about 5% of the total users within the organization, so it seems crazy to run an import where 95% of it will be useless...
Tim - you need to import the users and groups. Unless your directory is gigantic, this typically isn't going to cause too much stress (my customer pulls several thousand users in just about 15 minutes).
If possible, I always put the users that will log in with FBA into a separate OU to avoid pulling the entire directory. Of course, this works wonders in a lab scenario where I have full control of everything, but that may not be the case here. If you can't put those users in a different container or filter based on some condition (such as department), then consider writing a custom sync process if the out of box solution doesn't fit your needs.
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!
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.
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.
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?