LDAP connetion

May 31, 2013 at 7:04 PM
Edited May 31, 2013 at 8:22 PM
I'm federating users (account forest) from a different domain (domain the server is in is untrusted by the domain the users are in) than the server is in (resource forest). When manually specifying the username and account to use, it errors with a bad username password error, because it looks like the connection attempt is being made with the application pool account of central admin, which would give this error as expected. LDAP queries aren't domain trust dependent, so I'm wondering why this error? Why wouldn't it just connect with the account I specified?? As expected the accounts don't resolve. Is there a work-around to this?
May 31, 2013 at 8:42 PM
Actually figured it out...used the serverbind mode. Not as ideal since it is relying on a single DC being up, but at least it works!
Jun 3, 2013 at 11:16 AM
Ok :)
Jul 12, 2013 at 2:01 PM
Hi Yvand,
We have the same scenario, SharePoint farm is in a domain not trusted by the domain where users are. We are planning on installing this solution to have the people picker resolve names and allow searching. Two questions:

1) Could you please elaborate on how you use "the serverbind mode"
2) Can I associate this claims provider with the existing trusted login provider, which is ADFS 2.0 in a way that the existing accounts that have been already assigned permissions continue to work. In other words, we would like to not have to re-enter all user permissions.

Jul 15, 2013 at 11:14 AM

I don't have much to say about the server bind mode. It's an authentication option that is part of the API and you can the description here: http://msdn.microsoft.com/en-us/library/system.directoryservices.authenticationtypes.aspx.

Regarding the point 2, no worries the claims provider has no impact on permissions already defined. It's only used to assign new permissions.
With that being said, every time an existing permission will be loaded in the people picker the claims provider will be called to validate it. If for some reason it cannot validate, SharePoint will display it as unresolved.

Jul 16, 2013 at 7:13 PM
Found the root cause of the issue...the FQDN and netbios name of the domain (user forest) are different. This requires using the FQDN for the LDAP connection string, i.e. LDAP://FQDN

If the names are the same, it shouldn't be an issue because DNS should take care of it assuming it is setup properly to handle this. On another slightly related note, I also ound out this affect user profile sync connections. When specifying the account name, if there isn't a trust, you also have to enter the username in the format of FQDN\username rather than domain\username with domain being the netbios name. Otherwise you will get an error when saving the sync connection.
Jul 24, 2013 at 6:44 PM
Hi Yvand. Thanks for your reply. We installed your solution on a test server and the people picker is successfully resolving users from ADFS20. We were also able to bring the email address from LDAP into the SharePoint user profile when a new user is added.

However, the name of the user in SharePoint, which we want to display as "Lastname, Firstname" is only showing the AD username, for example, JDOE. The username is what is configured in ADFS to use as the claim but we would like to bring over the LDAP attribute called displayName which is in the format Doe, John. The userdisp.aspx page shows these attributes for a newly added user:

Account: i:0ǵ.t|adfs20|jdoe
Name: jdoe
Work e-mail: jdoe@domain.com The "Name" above is what shows in the dropdown at the top right of SharePoint pages when users login but we want this "Name" to be "Doe, John" instead of jdoe. We've tried adding different claim mapping entries but have been unsuccessful in accomplishing this. The name continues to come in as the username. Any ideas? Thanks!
Jul 25, 2013 at 12:33 PM
the custom display name shoulw work as you want if you go to LDAPCP administration page and you select option "Always use a specific LDAP attribute for the display text of the permission”, and set attribute “displayName"
But keep in mind that at the end it will be always overwritten by the "Preferred name" attribute in the user profiles service application.
I hope this is clear