Click here to visit project for SharePoint 2010 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:

Joe boss

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 in its GAC. In that case, you must manually add it or some features may not work. In SharePoint 2013 (.NET 4.5), the GAC is located in C:\Windows\Microsoft.NET\assembly.

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 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" in SharePoint logs.

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

For an unknown reason, randomly SharePoint 2013 doesn’t uninstall correctly the solution because it tries to call the feature receiver (that removes the claim provider) after it removed the assembly from the GAC… When this happens, the claim provider is not removed from the farm and that creates problems when you try to re-install it.

To avoid any issue, deactivate the farm feature before retracting the solution:


Disable-SPFeature -identity "LDAPCP"
Uninstall-SPSolution -Identity "LDAPCP.wsp"
Remove-SPSolution -Identity "LDAPCP.wsp"

Validate that claims provider was removed: “Get-SPClaimProvider| ft DisplayName”. If LDAPCP appears, remove it: “Remove-SPClaimProvider LDAPCP”

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

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
  • Customize display of results
  • 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.

Common mistakes to avoid:

  • Always deactivate the farm feature before retracting the solution (see “how to remove” above to understand why).
  • When you create your own SharePoint solution, DO NOT forget to include the ldapcp.dll assembly in the wsp package.

If you did any of the mistakes above, you will likely experience issues when you try to redeploy the solution 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:06 PM by yvand, version 122