I have read through most of the posts on this site relating to the integration of SharePoint 2013 FBA with an external non-AD LDAP (Tivoli Directory Server). As a matter of fact, using the instructions (verbatim) at https://technet.microsoft.com/en-us/library/ee806890.aspx,
we had our SharePoint users authenticating without a problem. Unfortunately, recent security mandates across the company now demand all connections to the LDAP DS be secured by SSL. The DS no longer supports connections over port 389.
So I went into the 3 web.config files (SharePoint Central Administration v4, Security Token Service, and the web application itself) and changedonly the following values:
port="636"
useSSL="true"
Further, I imported the SSL certificate from the LDAP DS into the local computer personal store of the SharePoint server. Users are still unable to authenticate to LDAP via FBA. Our DS accepts anonymous connections (I tested this out using a third-part LDAP
browser directly on the SharePoint server). Here are a few clues to understanding the issue:
- Filtering the ULS log results out for Claims Authentication and Authentication Authorization, the first thing I see in the authentication chain is the following error:
Token Handler: Claims Forms Sign-In: Membership Provider 'LDAPMember' username-password check for user 'user@company.com' failed.
STS Call and SPSecurityContext errors follow, as expected. Since this only shows that the check failed but doesn't tell me why, I decided to do a trace with Message Analyzer.
- A Message Analyzer local network trace reveals that SharePoint is making a connection (binding) to the LDAP DS but, for some strange reason, insists on passing what appears to be the Farm Admin as CN and a composite of the SSL certificate's OUs and DCs.
After that, it automatically unbinds:
Bind Operation, MessageID:2233, Result:Success
Search Operation, MessageID:2234, Search On
BaseObject:CN=WSSFarmAdmin,OU=Users,OU=Infrastructure Objects,OU=City,DC=Department,DC=company,DC=com
LDAP Message, Unbind Request, MessageID: 2235
So logic would infer that FBA is attempting to check the existence of the user in LDAP but is using a CN it doesn't recognize to perform the search operation. Now, would this have an effect on a server that accepts anonymous connections? Here is where I
don't understand what's going on under the hood deeply enough and need some guidance.
I have tried passing a valid LDAP username / password with ConnectionUsername and ConnectionPassword variables. I even tried setting them both to a blank string. Another thing I tried was setting useDNAttribute to "true", thinking that perhaps
that would have an effect on the BaseObject which FBA is passing to perform the search.
What am I missing? I don't have access to the LDAP DS. It is in a secured data center with its own set of administrators. The best I can hope for is to trace communications from the SharePoint server, which is what I have already done.
Is that BaseObject a red herring? The DS accepts a connection and allows search operations using an LDAP client. What can I do to the SharePoint configuration to allow it to behave similarly? It shouldn't be this difficult.