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 uiddn: 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 636110 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 slapdslapd: ALL I can see the server running and listening on port 636:> netstat -l | grep ldapstcp 0 0 *:ldaps *:* LISTEN tcp 0 0 *:ldaps *:* LISTEN> ps auxww | grep slapdldap 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. -- Paul (ganci at nurdog.com)
Greetings, On Mon, Feb 22, 2010 at 11:18 AM, Paul R. Ganci <ganci at nurdog.com> wrote:> Hi All, > > Everything works as expected. However if I try the same command from a > remote machine remote.mydomain.com the command just hangs.Sorry if you have already checked it. In you remote.mydomain.com, does /etc/hosts contain entry for LDAP server? IOW does the names resolve? Are you able to do the query using IP addresses? Any evidence/trace of the query packets travelling in the net (say using wireshark)? I usually go this way when confronted with such situation. Is LDAP configured to be query-able without any passwords. (I may not be too clear here though) HTH Regards, Rajagopal -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.centos.org/pipermail/centos/attachments/20100222/8ee7ed28/attachment.html>
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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.