On Sun, 2010-02-21 at 22:48 -0700, Paul R. Ganci wrote:
Hi All,
I am at my wits end. I have a LDAP server setup on a machine (the names are changed to protect the innocent) example.mydomain.com running CentOS 5.4 and LDAP version 2.3.43-3. If I issue a ldapsearch command while logged onto the LDAP server host I get a valid response back. For example:
ldapsearch -x -LLL -H ldaps://example.mydomain.com:636 "(uid=joker)" \ sn uid
dn: uid=joker,ou=People,dc=mydomain,dc=com uid: joker sn: Nicholson
Everything works as expected. However if I try the same command from a remote machine remote.mydomain.com the command just hangs. I can not find a log entry anywhere that indicates something is wrong. I have checked the obvious things I can check. For example I know that port 636 is open:
/etc/rc.d/init.d/iptables status | grep 636
110 ACCEPT tcp -- 0.0.0.0/0 208.139.195.124 state NEW,ESTABLISHED tcp dpt:636 111 ACCEPT udp -- 0.0.0.0/0 208.139.195.124 state NEW,ESTABLISHED udp dpt:636
I have enabled access via /etc/hosts.allow:
cat /etc/hosts.allow | grep slapd
slapd: ALL
I can see the server running and listening on port 636:
netstat -l | grep ldaps
tcp 0 0 *:ldaps *:* LISTEN tcp 0 0 *:ldaps *:* LISTEN
ps auxww | grep slapd
ldap 21865 0.0 0.2 467976 5860 ? Ssl 19:54 0:02 /usr/sbin/slapd -h ldap:/// ldaps:/// -u ldap
I am missing something very obvious. Can anyone offer any clues? Thanks.
---- ldap ssl is deprecated but should actually still work.
Do you actually have to specify the port number? I don't think so...
-H ldaps://example.mydomain.com should be sufficient
The preferred method is TLS (via standard -h ldap://example.mydomain.com uri notation)
Note that ldap 'client' applications like ldapsearch use /etc/openldap/ldap.conf so I would suspect that the 'certificates' used by the 2 machines are different.
add -d 256 (or even higher debug level) to the ldapsearch command for debugging - I'm not going to hazard any actual guesses.
Craig