This project has moved and is read-only. For the latest updates, please go here.

change the objectclass

Jan 30, 2014 at 12:29 AM
What is the easiest way to change the objectclass from user to inetorgPerson to use with a Sun Directory?

Jan 30, 2014 at 1:11 PM

with the standard version you can't but I will definitely consider to add it in the next version, considering the need with Sun Directory.

Currently, it's easy if you have developer skills and download the package "LDAPCP 2013 for Developers":
In sample class LDAPCP_Custom, you would need to change each "AttributeHelper" required in method "PopulateAttributesDefinition" to set property "LDAPObjectClass" to "inetorgPerson" instead of "user".

Feb 5, 2014 at 5:00 AM
We have struggled with getting a people picker to work in our environment for a long time. Your solution is very well done, and we are very hopeful that we are close to moving forward on this.

I work with Christopher, and we were able to solve the object class issue by simply setting the value in the claim mapper page. But for some reason the results from the LDAP query, which we can see coming back to sharepoint in a network trace are not being displayed for the user. Is there anything necessary when setting up the SPTrustedRootAuthority ?

New-SPTrustedRootAuthority "PingSTSRootAuthority" -Certificate $rootcert | Out-Null

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($certloc)

$map1 = New-SPClaimTypeMapping -IncomingClaimType "" -IncomingClaimTypeDisplayName "Ping UPN Claim" -LocalClaimType ""

$apSAML = New-SPTrustedIdentityTokenIssuer -Name "PingSTS"-Description "PingSTS" -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl "" -IdentifierClaim""

$cpSAML = New-SPClaimsPrincipal -TrustedIdentityTokenIssuer $apSAML -Identity "administrator"
Feb 5, 2014 at 5:03 PM

thanks a lot for your feedback.
Indeed, you can definitely use the claims mapping page, it's so obvious I didn't think about it...

And no you don't have to change anything on the SPTrustedRootAuthority, but looking at the PowerShell script, I think the issue comes from the identity claim type.
Can you confirm if users are able to authenticate in SharePoint (whatever the claims provider is used or not)?
In this particular setup, it might fail because LDAPCP may expect to find identity claim type "" in the mapped claims list, but will not find it since it is transformed in "".
You will get more information if you check SharePoint logs and filter on category "LDAPCP"
please keep me posted.