The configuration is reasonably complex and determining where an error lies is a balancing act between windows event viewer, LDAP logs and ULS logs.
One such error I received during my SP and OpenLDAP configuration was an event viewer application log.
Source: SharePoint Foundation
Event ID: 8306
Task: Claims Authentication
Error: An exception occured when trying to issue security token: The security token username and password could not be validated..
This error is accompanied with the inability to login to your SP site. A quick google search turned up a number of users in the same boat and plenty of suggestions but no definitive answers.
Clumsy Configuration
When you are working from configuration samples and writing large portions of text based configuration there is always the possibility of data entry errors.
Any of the tutorials you follow, such as this one, will ask you to create a new web application, select claims based authentication and then do some manual configuration in some of the web.config files on your SP site.
This is where the doubt creeps in, during the configuration of a membership provider, depending on the tutorial you are reading, you may be asked to configure a "ASP.net membership provider" with "useDNAttribute" or "userDNAttribute" or both.
As soon as I removed "userDNAttribute" and set "useDNAttribute" to false, everything worked for me and the security token validation error message disappeared. I am not sure if this is because I am using OpenLDAP or if that makes any difference at all.
The below configuration is an example of my working membership provider syntax.
<membership>
<providers>
<add name="LdapMember"
type="Microsoft.Office.Server.Security.LdapMembershipProvider,
Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c"
server="192.168.1.1
port="389"
useSSL="false"
useDNAttribute="false"
userNameAttribute="cn"
userContainer="ou=users,dc=contoso,dc=local"
userObjectClass="inetOrgPerson"
userFilter="(ObjectClass=inetOrgPerson)"
scope="Subtree"
connectionUsername="Cn=sharepointuser,dc=contoso,dc=local"
connectionPassword="password"
otherRequiredUserAttributes="title,sn,cn,mail,description"/>
</providers>
</membership>
Looking back retrospectively it seems like an obvious and easy to fix problem, but when there are so many variables at play it isn't always so easy.