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:
Anyone?????
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.
-philip
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
