You had said:

O/H Panos έγραψε:
the strange thing is that the ldapsearch command gives me this:
ldapsearch -x -b 'ou=users,dc=something,dc=something,dc=something' '(&(objectClass=*)(uid=ldap_test))'

# extended LDIF
# LDAPv3
# base <ou=users,dc=something,dc=something,dc=something> with scope subtree
# filter: (&(objectClass=*)(uid=ldap_test))
# requesting: ALL

dn: cn=ldap_test,dc=something,dc=something,dc=something
cn: ldap_test

gecos: ldap_test
homeDirectory: /home/ldap/ldap_test
loginShell: /bin/sh

uidNumber: 1003
uid: ldap_test
gidNumber: 1000
userPassword:: XXXXXX

And then later:

O/H Panos έγραψε:
I think I found what is the problem but I don't kow how to fix it.
from the error messages err=49 means that the password is wrong.
I'm sure that I type it correctly.
So I captured traffic using whireshark

when the manager tires toy bind everything is normal and the bind is succeful. In the field authentication simple of the packet the password was the correct but when ldap_test tries to bind the password that it send to ldap server is INCORECT (0000 08 0a 0d 7f 49 4e 43 4f 52 52 45 43 54 the hex field), so ldap server returns invalid credentials.

I think that this is the problem but I don't have a clue how to solve it. I can't understand why it sends an incorect password, and most important which of ssh, pam, pam_ldap has the problem.

Any ideas?

On 2009, Apr 23, at 09:54, Panos wrote:

With the "later" message where you say you found a message that the bind attempt resulted in the password reported as "INCORRECT", I do not see you describe how you initiated the BIND attempt, only that you captured it with wireshark.

When you login as "cn=manager,[...]" that you say works, is that via ssh, or your admin tool you mentioned in a previous message, or more directly using something like ldapsearch(1)?

I highly recommend you test things from the ground-up to try and find at which level the failure is occurring:

network (already covered, you know you can talk to the LDAP server from the client you are testing)

LDAP: Try performing the LDAP searches "manually" using ldapsearch(1), more on that below

        Account: getent passwd ldap_test

        SSH: If those work, try more logging in the PAM or SSH layers

For doing the direct LDAP test, you've already checked that the entry is in your database:

ldapsearch -x -b 'ou=users,dc=something,dc=something,dc=something' '(&(objectClass=*)(uid=ldap_test))'

next, make sure you can actually bind as that user:

% ldapsearch -x -b 'ou=users,dc=something,dc=something,dc=something' - D 'cn=ldap_test,dc=something,dc=something,dc=something' -W '(&(objectClass=*)(uid=ldap_test))'
        Enter LDAP Password: xxxxx

If that fails, bump up the logging on either the client and/or server side of the LDAP server and see what clues you get from those logs. If it works, move on to the next layer and see if it can properly access the information you could get manually.


_______________________________________________ mailing list
To unsubscribe, send any mail to ""

Reply via email to