PAM-SSH-LDAP problem

[Philip Kizer]

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