thanks a lot for your answer. I'm going to test your new version as soon as possible and tell you if i have found the solution.
Many thanks.
This claims provider queries Active Directory and LDAP servers to enhance people picker with a great search experience in trusted authentication (typically ADFS).
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.
You must manually deploy ldapcp.dll on SharePoint servers that do not have SharePoint service "Microsoft SharePoint Foundation Web Application" started. You can use this PowerShell script:
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Data\Dev\ldapcp.dll")
Version 2 is a critical update that ensures thread safety and fully implements SharePoint logging infrastructure (messages are recorded in Area/Product "LDAPCP"). Its logging level can be customized with PowerShell or Central Administration.
Install and deploy the solution (that will automatically activate the “LDAPCP” farm-scoped feature):
Add-SPSolution -LiteralPath "PATH TO WSP FILE" Install-SPSolution -Identity "LDAPCP.wsp"-GACDeployment
At this point claim provider is inactive and it must be associated to an SPTrustedIdentityTokenIssuer to work:
$trust = Get-SPTrustedIdentityTokenIssuer "SPTRUST NAME"$trust.ClaimProviderName ="LDAPCP"$trust.Update()
Run Update-SPSolution cmdlet to start a timer job that that will deploy the update. You can monitor the progression in farm solutions page in central administration.
Update-SPSolution -GACDeployment -Identity "LDAPCP.wsp" -LiteralPath "C:\Data\Dev\LDAPCP.wsp"
For an unknown reason, randomly SharePoint 2013 doesn’t uninstall correctly the solution because it removes assembly from the GAC before calling the feature receiver... When this happens, the claims
provider is not removed and that causes issues when you re-install it.
To uninstall safely, 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"
LDAPCP has a default mapping between claim types and LDAP attributes, but this can be customized in “Claims table” page available in Central Administration/Security.
Default list is following:
Claim type | LDAP attribute name | LDAP object class |
---|---|---|
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | user | |
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname | sAMAccountName | user |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn | userPrincipalName | user |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | givenName | user |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality | physicalDeliveryOfficeName | user |
http://schemas.microsoft.com/ws/2008/06/identity/claims/role | sAMAccountName | group |
linked to identity claim | displayName | user |
linked to identity claim | cn | user |
linked to identity claim | sn | user |
None of the claim types above is mandatory in the SPTrust, but the identity claim must either be one of them, or added through LDAPCP admin pages.
Note that you should never have 2 identical claim types in the list, this would cause issues.
To enhance search experience, LDAPCP also queries user input against common LDAP attributes such as the display name (displayName) and the common name (cn).
Project has evolved a lot since the beginning, and now 99% of all possible customizations can be made with LDAPCP administration pages in standard solution. Possible customizations not covered by standard package that can be achieved with "LDAPCP for Developers.zip" are:
"LDAPCP for Developers.zip" 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:
If you did any of the mistakes above, you will likely experience issues when you try to redeploy the solution because the feature was already installed. All features in the solution must be uninstalled before it can be redeployed.
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.
This claims provider queries Active Directory and LDAP servers to enhance people picker with a great search experience in trusted authentication (typically ADFS).
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.
You must manually deploy ldapcp.dll on SharePoint servers that do not have SharePoint service "Microsoft SharePoint Foundation Web Application" started. You can use this PowerShell script:
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Data\Dev\ldapcp.dll")
Install and deploy the solution (that will automatically activate the “LDAPCP” farm-scoped feature):
Add-SPSolution -LiteralPath "PATH TO WSP FILE" Install-SPSolution -Identity "LDAPCP.wsp"-GACDeployment
At this point claim provider is inactive and it must be associated to an SPTrustedIdentityTokenIssuer to work:
$trust = Get-SPTrustedIdentityTokenIssuer "SPTRUST NAME"$trust.ClaimProviderName ="LDAPCP"$trust.Update()
Run Update-SPSolution cmdlet to start a timer job that that will deploy the update. You can monitor the progression in farm solutions page in central administration.
Update-SPSolution -GACDeployment -Identity "LDAPCP.wsp" -LiteralPath "C:\Data\Dev\LDAPCP.wsp"
For an unknown reason, randomly SharePoint 2013 doesn’t uninstall correctly the solution because it removes assembly from the GAC before calling the feature receiver... When this happens, the claims
provider is not removed and that causes issues when you re-install it.
To uninstall safely, 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"
LDAPCP has a default mapping between claim types and LDAP attributes, but this can be customized in “Claims table” page available in Central Administration/Security.
Default list is following:
Claim type | LDAP attribute name | LDAP object class |
---|---|---|
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress | user | |
http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname | sAMAccountName | user |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn | userPrincipalName | user |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname | givenName | user |
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/locality | physicalDeliveryOfficeName | user |
http://schemas.microsoft.com/ws/2008/06/identity/claims/role | sAMAccountName | group |
linked to identity claim | displayName | user |
linked to identity claim | cn | user |
linked to identity claim | sn | user |
None of the claim types above is mandatory in the SPTrust, but the identity claim must either be one of them, or added through LDAPCP admin pages.
Note that you should never have 2 identical claim types in the list, this would cause issues.
To enhance search experience, LDAPCP also queries user input against common LDAP attributes such as the display name (displayName) and the common name (cn).
Project has evolved a lot since the beginning, and now 99% of all possible customizations can be made with LDAPCP administration pages in standard solution. Possible customizations not covered by standard package that can be achieved with "LDAPCP for Developers.zip" are:
"LDAPCP for Developers.zip" 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:
If you did any of the mistakes above, you will likely experience issues when you try to redeploy the solution because the feature was already installed. All features in the solution must be uninstalled before it can be redeployed.
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.
Get-ADGroup "Project EPM-RIM" -Properties *
LastKnownParent :
mail : ProjectEPM-RIM@XXX.com
mailNickname : ProjectEPM-RIM
The same i see when looking for a user: Get-ADUser "Sergey_Solovyev" -Properties *
GivenName : Sergey
mail : Sergey_Solovyev@XXX.com
Name : Sergey Solovyev
ObjectClass : user
SamAccountName : Sergey_Solovyev
Surname : Solovyev
UserPrincipalName : Sergey_Solovyev@XXX.com
But when checking at SharePoint server, email is present for user, but not for group:$spti = Get-SPTrustedIdentityTokenIssuer
$claim9 = New-SPClaimsPrincipal -ClaimValue "Sergey_Solovyev@xxxx.com" -ClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn -TrustedIdentityTokenIssuer $spti
$user9 = $web.EnsureUser($claim9.ToEncodedString())
$user9 | Format-List -Property *
UserLogin : i:0e.t|staging adfs|sergey_solovyev@XXX.com
DisplayName : Sergey Solovyev
Name : Sergey Solovyev
Email : Sergey_Solovyev@XXX.com
$spti = Get-SPTrustedIdentityTokenIssuer
$claim10 = New-SPClaimsPrincipal -ClaimValue "Project EPM-GOPS" -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/role -TrustedIdentityTokenIssuer $spti
$user10 = $web.EnsureUser($claim10.ToEncodedString())
$user10 | Format-List -Property *
UserLogin : c:0-.t|staging adfs|project epm-gops
DisplayName : (Role) Project EPM-GOPS
Name : (Role) Project EPM-GOPS
Email :
Any suggestions on what i'm doing wrong?Get-ADGroup "Project EPM-RIM" -Properties *
LastKnownParent :
mail : ProjectEPM-RIM@XXX.com
mailNickname : ProjectEPM-RIM
The same i see when looking for a user: Get-ADUser "Sergey_Solovyev" -Properties *
GivenName : Sergey
mail : Sergey_Solovyev@XXX.com
Name : Sergey Solovyev
ObjectClass : user
SamAccountName : Sergey_Solovyev
Surname : Solovyev
UserPrincipalName : Sergey_Solovyev@XXX.com
But when checking at SharePoint server, email is present for user, but not for group:$spti = Get-SPTrustedIdentityTokenIssuer
$claim9 = New-SPClaimsPrincipal -ClaimValue "Sergey_Solovyev@xxxx.com" -ClaimType http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn -TrustedIdentityTokenIssuer $spti
$user9 = $web.EnsureUser($claim9.ToEncodedString())
$user9 | Format-List -Property *
UserLogin : i:0e.t|staging adfs|sergey_solovyev@XXX.com
DisplayName : Sergey Solovyev
Name : Sergey Solovyev
Email : Sergey_Solovyev@XXX.com
$spti = Get-SPTrustedIdentityTokenIssuer
$claim10 = New-SPClaimsPrincipal -ClaimValue "Project EPM-GOPS" -ClaimType http://schemas.microsoft.com/ws/2008/06/identity/claims/role -TrustedIdentityTokenIssuer $spti
$user10 = $web.EnsureUser($claim10.ToEncodedString())
$user10 | Format-List -Property *
UserLogin : c:0-.t|staging adfs|project epm-gops
DisplayName : (Role) Project EPM-GOPS
Name : (Role) Project EPM-GOPS
Email :
Please note that there is no possibility to create duplicate claim in LDAPCP configuration table.if (!string.Equals(a, input, StringComparison.InvariantCultureIgnoreCase))
continue;
}continue;
The code check that the result starts with the filled in input than delete some results such as herebelow:$logonName = "WFA FP&A"
$user = [AMPortal.Data.SPLists.Repositories.Base.WebExtension]::TryEnsureUser($web, $logonName)
Write-Host $user.LoginName $user.Name $user.Email
c:0 + .w|s-1-5-21-1292428093-113007714-1060284298-40795 WFA FP&A WFAFP&A@xxxx.com
$logonName = "WFA FP&A"
$user = [AMPortal.Data.SPLists.Repositories.Base.WebExtension]::TryEnsureUser($web, $logonName)
Write-Host $user.LoginName $user.Name $user.Email
c:0-.t|staging adfs|wfa fp&a (Role) WFA FP&A
PS TryEnsureUser is our implementation of SPWeb.EnsureUser()