Click here to visit project for SharePoint 2013 version.

In SAML authentication mode, SharePoint does not try to resolve user input in the people picker, and anything users type is validated without any check.
This claims provider implements lookup against Active Directory or any other LDAP, and comes with 2 administration pages (available under Central administration / Security) to customize many settings to fit most of the organization needs:

LDAPCP people picker Joe

For developers, this project provides a base class they can inherit to easily build their own claims provider. Read “Developers section” below for more information.

Important - Limitations

LDAPCP is inactive (visible in the people picker but not called) as long as it is not associated to a specific TrustedLoginProvider. This is done on purpose because it cannot create permissions for a trust if it is not associated to it.

Due to limitations of SharePoint API, do not associate LDAPCP with more than 1 TrustedLoginProvider. Developers can easily workaround this limitation by inheriting LDAPCP to create a new claims provider and use it with another TrustedLoginProvider (Read “Developers section” below).

If a SharePoint server does not have SharePoint service “Microsoft SharePoint Foundation Web Application” started, ldapcp.dll assembly will not be deployed to its GAC. In that case, you must manually add it or some features may not work. In SharePoint 2010 (.NET 3.5), the GAC is located in C:\Windows\assembly.

How to install it

Install and deploy the solution (that will automatically activate the feature at farm level):

Add-SPSolution -LiteralPath "PATH TO WSP FILE"
Install-SPSolution -Identity "LDAPCP.wsp" -GACDeployment

At this point claim provider is inactive (see "Important - Limitations") and it must be associated to a TrustedLoginProvider to work.
Associate it with a TrustedLoginProvider using the following PowerShell commands:

$trust = Get-SPTrustedIdentityTokenIssuer "TRUSTEDLOGINPROVIDER NAME"
$trust.ClaimProviderName = "LDAPCP"

No need to do an IISRESET, it is immediately applied on every web application using the TrustedLoginProvider.

The activity of the claim provider can be monitored by looking at the category "LDAPCP" ("LDAP Claim Provider" for old versions) in SharePoint logs.

How to update LDAPCP

Simply run Update-SPSolution cmdlet:

Update-SPSolution -GACDeployment -Identity "LDAPCP.wsp" -LiteralPath "C:\Dev\LDAPCP.wsp"

How to remove LDAPCP

Retracting and deleting the solution completely removes LDAPCP from SharePoint:


Uninstall-SPSolution -Identity "LDAPCP.wsp"
Remove-SPSolution -Identity "LDAPCP.wsp"

Claims supported

LDAPCP has a default mapping between claim types and LDAP attributes, but you can easily change it from “Claims table” page available in Central Administration > Security.
Default list is following:

Claim type LDAP attribute name LDAP object class mail user sAMAccountName user userPrincipalName user givenName user physicalDeliveryOfficeName user sAMAccountName group
linked to identity claim displayName user
linked to identity claim cn user
linked to identity claim sn user


Note that none of those claim type is mandatory in the trust configuration, but the identity claim must be one of them (LDAPCP will automatically detect it).

It also queries input against common LDAP attributes even if they are not defined in the trust. Those attributes are the display name (displayName) and the common name (cn)

Developers corner

Developers can download "LDAPCP for" (available in Downloads section) to inherit LDAPCP class for specific needs:

  • Customize list that maps claim types with LDAP attributes
  • Associate LDAPCP to multiple TrustedLoginProviders
  • Connect to multiple LDAP / AD in the same claim provider
  • Set a keyword to resolve an input without LDAP lookup
  • Set a prefix that should be added to a value returned from LDAP when creating the permission

"LDAPCP for" contains a Visual Studio project with sample classes that cover various use-case scenarios. Only 1 inherited claim provider is installed at a time, you need to edit the feature event receiver to install the claim provider you want to test.

When you create your own SharePoint solution, DO NOT forget to include the ldapcp.dll assembly in the wsp package, otherwise solution will fail to deploy and it’s a pain to fix (I’ll provide a how-to later).

In any case, DO NOT directly edit LDAPCP class, it has been designed to be inherited so that you can customize it to fit your needs. If a scenario that you need is not covered, please submit it in the discussions tab.

Last edited Oct 22, 2013 at 12:05 PM by yvand, version 14