Hi,
I installed sldap 2.4.18 on server debian squeeze (here 172.19.6.150)
when Iuse the command
ldapsearch -xLLL -b "dc=example,dc=com" uid=john sn givenName cn
dn: uid=john,ou=people,dc=example,dc=com
sn: Doe
givenName: John
cn: John Doe

I get correct answer

I tried to do it from a remote machine where ( ubuntu 9.10 ) (IP 172.19.6.50)
I installed package for authentication in this client machine

libnss-ldap
ldap-auth-config
I ran pam-auth-update

everything seemed correct like it is decalred in the document

http://doc.ubuntu.com/ubuntu/serverg...ap-server.html

I used ubuntu doc, because I have install 2.4.18 ( not present yet on squeeze),
on some machine it running correctly, on other not!!!??


I got the error : ( it is running on another machine : 172.19.6.50 )

ldapsearch -xLLL -b -H ldap://172.19.6.150 "dc=example,dc=com" uid=john sn givenName cn

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)

in the same way , the authentication is not done ( john is created in ldap server)

su - john
identifier unknown : john


I can do same from another machine running debian lenny. very strange I install same packages, that what I believe

any idea
thanks a lot

well from that it initially looks like you aren't able to reach 172.19.6.150 on port 389 at the network level, as this address does not figure in the first example. where are you going at a TCP level in that first example? Also what does your server side logs say about this? AFAIR, the "can't contact" doesn't exclusively mean a tcp issue - although I think the other alternative root causes relate more to SSL which you are not using there.

Thanks chris
the difference between the 2 examples, is in the first I check the command on the local machine wich is the server (172.19.6.150) in the 2nd i did it from a remote client (172.19.6.50 ). Since I received the answer in the first case this means the server is running correctly, may be the error is in the client itself, ldap client ???

thanks again
best regards
bela

I wouldn't expect it to be the client, more likely the network or firewall rules on the server. try doing a telnet to port 389 on that IP from the client to reduce things to a simpler level.