Le 29 juin 09 à 12:04, Reapepr a écrit : Invalid credential : your bind to the ldap server failed (but invalid credential error don't provide the explanation by itself). Are you storing plain text password or hash values within your ldap server ? I suspect xwiki to send clear text password (over a secure channel would you enable ldaps) so if you store hash values, the ldap server compare the plain text password to the hash version, resulting in invalid credential (password string being different). HTH and sorry would this be not relevant to your referred issue (I'm just a user ;-)).

Le 30 juin 09 à 09:49, Reapepr a écrit : Try to add another "uniquePassword" attribute with a plain text password for a user in the directiry, and retry authentication. If the auth work, we identified the problem. Else the issue is elsewhere. You need to test it. I am experiencing the same issue (hash pwd in directory, and xwiki sending plain text password). I guess the only way (without much work around on the application itself) would be to add SASL mechanism in front end to your directory (SASL would hash the password for the directoiry, if I'm correct !). I couldn't test this idea however (time :/) and therefore I am stuck at the very same point in xwiki adoption. Hope This Helps ;-)

Le 30 juin 09 à 11:13, Thomas Mortagne a écrit : Yes I understand the architecture choice to lead to plain text pwd in secured channels, and that's fine (clenat can't provide all past and future hash mechanisms, neither the one to use with the connected directory). Nevertheless, I am using OpenLdap (slapd 2.4.11) with no specific configuration, and nevertheless the ldap directiry does not hash the plain text password sent :/ Would you have an idea on which specific option may prevent this behavior, I can make some tests !