On Fri, Mar 04, 2011 at 11:01:28AM +0000, mahaoboy@gmail.com wrote:

To: openldap-its@openldap.org

This is not a bug-report at this stage so I am directing replies to openldap-technical@openldap.org.

This user can logged in confluence successfully, but when could not log in fisheye.

Log of confluence logging:

conn=5 op=8052 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))"

conn=5 op=8052 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" conn=5 op=8052 SEARCH RESULT tag=101 err=0 nentries=1 text=

conn=8 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=8 op=0 BIND dn="cn=jirasupport,ou=People,ou=eejira,o=nsn" mech=SIMPLE ssf=0 conn=8 op=0 RESULT tag=97 err=0 text=

All OK so far.

Log of fisheye logging:

conn=5 op=8051 SRCH base="ou=eejira,o=nsn" scope=2 deref=3 filter="(&(objectClass=person)(uid=jirasupport))"

conn=5 op=8051 ENTRY dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" conn=5 op=8051 SEARCH RESULT tag=101 err=0 nentries=1 text=

conn=7 op=0 BIND dn="cn=jirasupport,ou=people,ou=eejira,o=nsn" method=128 conn=7 op=0 RESULT tag=97 err=49 text=

Error 49 (decimal) is 0x31 (hex) which is LDAP_INVALID_CREDENTIALS so the password does not match.

And other users are all right for logging in all applications.

My guess would be that there is something odd about this user's password. Be aware that most existing LDAP client software treats passwords as strings of binary without consideration of character set encoding. This can lead to problems where an account has a password that cannot be represented in 7-bit ASCII. There is nothing that the LDAP server can do about this, as it does not know what character set the application is using.

I would suggest changing this account's password to a new one using only printable 7-bit characters. You can maintain good security by making the password longer (but beware that the old Unix-crypt hash scheme only uses the first 8 characters so avoid that if you can: SSHA1 is far better).

Andrew