SharePoint 2013 Configure People Picker to Resolve ADFS Identities


In this article we will show some of the unintended side-effects of implementing SAML Claims authentication.  Additionally we will attempt to provide a solution for these problems that has been brought forth by the SharePoint community.

Unintended Side-effects

ONe of the side effects of using a SAML authentication provider in SharePoint is that once you start using that provider the people picker will no longer try to resolve users. For example when trying to add a user to the site the people picker will parrot back whatever is typed in the box:


You will also notice that it brings back two entries; EmailAddress and Role.  Each one of these entries relates to a claim that is being passed back by ADFS.  In this lab environment these are the only two claims we have mapped.



Fortunately there has been some independent development work that have created a few solutions.  One of these solutions is a LDAP/AD claims provider located at Codeplex and can be found here.

Install and Deploy LDAPCP Solution

We’ll go ahead and download the solution file and place it on our SharePoint server. Any server that is a member of the farm will do.  Start up an elevated privileged SharePoint Management Shell.


Next add the solution to the farm using the “Add-SPSolution” cmdlet and then install the solution via the “Install-SPSolution” cmdlet.

<br />Add-SPSolution –LiteralPath<br />Install-SPSolution –Identity “ldapcp.wcp” –GACDeployment<br />


Wait a couple of minutes to make sure the solution has had time to deploy.  We can verify the deployment in Central Administration.  Navigate to “System Settings”.


Under “Farm Management” navigate to “Manage Farm Solutions”.


Here we can see that he solution has indicated that it is “Deployed”.


Associate LDAPCP with the Trusted Claims Provider

Now that the solution has been installed and deployed we need to associate it with the Trusted Claims Provider.

We will need to get the name of your claims provider if you don’t already know it. Assuming you only have one claims provider (which is all that is supported for this codeplex solution) then you can retrieve the name needed for the deployment with the following commands.

<br />Get-SPTrustedIdentityTokenIssuer|select name<br />


Use the following PowerShell script to associate the new claims provider to the Token Issuer.

<br />$ap = Get-SPTrustedIdentityTokenIssuer “PROVIDER NAME”<br />$ap.ClaimProviderName = “LDAPCP”<br />$ap.Update()<br />



That’s it!  If everything went smoothly you should now be able to properly resolve account within SharePoint using SAML claims authentication.


Tagged with: , , , , ,
Posted in SAML Claims, SharePoint 2013, Troubleshooting
17 comments on “SharePoint 2013 Configure People Picker to Resolve ADFS Identities
  1. Drew says:

    When I did this the solution did not get deployed to my central administration WFE where I have search running and it broke search. How can I force LDAPCP to be deployed there?

    • Yvan says:

      hello, does the central administration have the web application service enabled?
      If not, the assembly has not been deployed in the GAC of this server. In this case, you can simply manually add ldapcp.dll in the GAC of this server

  2. Anu says:

    Hello….I have successfully deployed, but iam getting users from the other domain as well in one of my WFE’s and in the other it is working fine. not sure what went wrong.
    Please help me in this case.

    Thanks in advance for the help. thank you.


    • whorn76 says:

      I’m not sure why which WFE you’re connected too would make a difference to what you’re seeing. Are you saying you’re seeing users from the normal AD domain as well as you Trusted Identity Provider? If so you may want to look at hiding your AD users:


      • Anu says:

        Hi Whorn
        Thank you for your reply.

        The issue is due to the cache data.
        Please clarify – in the people picker iam getting 3 results
        2 for Login and 1 for email address.

        To restrict this to one, do i need to remove the claimtype mappings associated?

        Please suggest.

        Thanks in advance.


    • whorn76 says:

      I guess maybe I’m not exactly understanding your issue. In your people picker field when you search for the user are you seeing the email address as well as their AD account?

      If so you will need to Hide the AD provider as stated above to prevent the AD credentials from being selectable through the People Picker.

      If you have already done that and they are still showing up, it may be because they are already in the users information list.

      If you list out the users of the site with powershell:

      Get-SpUser -web |select userlogin,displayname

      Do you see the 3 accounts you’re refering too?

      You can remove these accounts by using remove-spuser and they will no longer show up in the cached people picker. Unless that user account is added back into the user information list.


      • Anu says:

        Thank you for your time to reply.

        Iam seeing three different results from SAMAccount itself. It is not AD account.
        My structure is as below

        All Search Results
        All Users(0)
        Organisations (0)

        The results at right hand side for login(2) are as below :
        1. same as AD display(user display name followed by designation
        Ex: Jahnavi, Anu Manager,IT Department.
        2. Anu Jahnavi

        the results under emailaddress(1)
        3. (emailaddress)

        defalut authentication (AD) is hidden.
        I guess these are for the claim’s that are given(Login,UPN,Givenname).

        I want to get only the first one from the results (i.e., Jahnavi, Anu Manager, IT Department). Need to restrict the rest.How can i do that.

        Please suggest, thanks.

  3. whorn76 says:

    After you deployed the LDAPCP solution did you associate it with the Trusted Claims Provider like described at the bottom of this article?

  4. supermonggo says:

    I created mapping using email for my SpTrustedTokenIssue as the following:

    $snapin = (Get-PSSnapin -name Microsoft.SharePoint.PowerShell -EA SilentlyContinue)
    IF ($snapin -ne $null){
    write-host -f Green “SharePoint Snap-in is loaded… No Action taken”}
    ELSE {
    write-host -f Yellow “SharePoint Snap-in not found… Loading now”
    Add-PSSnapin Microsoft.SharePoint.PowerShell
    write-host -f Green “SharePoint Snap-in is now loaded”}

    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“D:\ADFS certificate\ADFS.cer”)

    $mail= New-SPClaimTypeMapping -IncomingClaimType “” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

    $realm = “urn:sharepoint:contoso:443”
    $signInURL = “”

    $ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS Local” -Description “Connect to Dev” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $mail -SignInUrl $signInURL -IdentifierClaim $mail.InputClaimType
    $ap.ProviderRealms.Add(“https://contoso”, “urn:sharepoint:contoso:443″)

    After the SPTrustedIdentityTokenIssue is created, then i assigned LDAPCP as my claim provider:
    $t = Get-SPTrustedIdentityTokenIssuer
    $t.ClaimProviderName =”LDAPCP”

    All created as expected.

    Then when i login as windows authentication, i add some claim users as sitecollection administrator (e.g

    Now, i am trying to use of of claim users which is in SiteCollection administrator.

    however, i could not login. The error said “The site has not been shared with you”

    Then, i logged on again using windows authentication to confirm that jack.nicholson has the the correct username and permission.

    Please advise, thank you

    • whorn76 says:


      I’m trying to understand what you’re running into here. Are you saying that when you login using ADFS you are able to access with your ADFS Claims account (the email address), but when you log with Windows Authentication your normal NTLM account doesn’t have access to the site?

      Are both users setup to have access to that Site Collection?



  5. Hey, this is a great post. I am wonder if I can use this to connect to any LDAP directory, such as Novell Edirectory?

  6. Andreas says:

    Does the SharePoint Server have to have direct Access to the LDAP Server for this to work?


  7. Danny says:

    Don’t know if this tread is still monitored ?

    I need to filter the people picker depending on HNSC.
    In other words – the filter changes according to the site-collection the search is issued from.
    Thru configuration if possible or coding if necessary.

    All pointers welcome


  8. TechieTrev says:

    Thanks for this solution. Hoping someone is still monitoring this forum? We have deployed this solution to our SP2013 farm and have hidden return of AD ‘DOMAIN\User’ accounts from people picker. People picker is now returning 2 items for our AD users; Email Address, and UPN. As there are a small group of users on our domain that don’t have an email address, we want to standardize on granting permission based on selection of UPN and want to hide email address selection as second choice on People Picker. Was hoping to tweak so that ONLY UPN is presented to prevent user choosing email address when granting permission. Anyone can point me to how that would be accomplished?

  9. afaik, setting the identifier claim type to UPN will do the trick :
    $map = New-SPClaimTypeMapping -IncomingClaimType “” -IncomingClaimTypeDisplayName “UPN” -SameAsIncoming


    $ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS Provider” -Description “SharePoint secured by ADFS” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map -SignInUrl “https://……-2013.kering.local/adfs/ls” -IdentifierClaim “”

    Ensure you passthru the UPN to sharepoint in ADFS relaying party.

  10. Michel Fleitas says:

    Greate Post! I have a doubt, How I can show the user display name instead the user email in the people picker?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: