This project is read-only.

Click here to visit LDAPCP for SharePoint 2013.

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 this:

LDAPCP people picker Joe 


Many settings can be customized by administrators through administration pages available in Central administration > Security, which include the following:

  • Connect to multiple LDAP / AD.
  • Customize list of claim types used, and their mapping with LDAP attributes.
  • Set a custom LDAP filter for each claim type, for example to only return users that are member of a specific security group.
  • Set a keyword to resolve an input without LDAP lookup. For example, input "" creates permission "" on configured claim type, even though it doesn’t exist in LDAP.
  • Set a prefix to add to LDAP results, for example add "domain\" to groups returned by LDAP.

Important - Limitations

LDAPCP is inactive as long as it is not associated to a specific SPTrustedIdentityTokenIssuer. Read instructions below to install it.

Due to limitations of SharePoint API, do not associate LDAPCP with more than 1 SPTrustedIdentityTokenIssuer. Developers can bypass this limitation by inheriting LDAPCP to create new claims providers (with different names). Read “Developers section” below for further information.

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.

Version 4 is a critical update that ensures thread safety and it is highly recommended to use at least this version. Click here to learn more.

How to install LDAPCP

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 SPTrustedIdentityTokenIssuer to work.
Associate it with a SPTrustedIdentityTokenIssuer using the following PowerShell commands:

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

No need to run IISRESET.

Starting with v4, SharePoint logging infrastructure is fully implemented and LDAPCP records messages in Area/Product "LDAPCP". Its logging level can be customized as needed through PowerShell or central admin.

How to update LDAPCP

Simply run Update-SPSolution cmdlet and wait for the timer job to deploy the update (you can monitor the progress in farm solutions page). Note that it will recycle central administration site.

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 user input against common LDAP attributes such as the display name (displayName) and the common name (cn), even if they are not defined in the trust.

Developers corner

Project has evolved a lot since the 1st release, and now 99% of all possible customizations can be made with administration pages in standard package. The only reason why a developer would need to download "LDAPCP for" is to use LDAPCP in multiple trusts (SPTrustedIdentityTokenIssuer objects), so that each trust has a claim provider with a unique name.

"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 Jun 19, 2014 at 9:37 AM by yvand, version 17