[SOLVED] openldap client fails to connect ldap server 'ldap_bind: Can't contact LDAP server'

JALITE · 09-28-2010, 07:11 AM

Just installed openldap server on a VM CentOS called 'ldapsrv', it works fine, ldapsearch returns all ldap information.
Installed openldap client on another VM CentOS called 'ldapclient1', configured it with most basic configuration, no ssl/tls etc. but ldapsearch returns error:
[root@ldapclient1 ~]# ldapsearch -x -b "dc=jacklan,dc=com"
ldap_bind: Can't contact LDAP server (-1)

ldapsrv is pingable:
[root@ldapclient1 ~]# ping ldapsrv
PING ldapsrv.jacklan.com (192.168.1.130) 56(84) bytes of data.
64 bytes from ldapsrv.jacklan.com (192.168.1.130): icmp_seq=1 ttl=64 time=2.66 ms

Some outputs:
from ldapsrv

PHP Code:



[root@ldapsrv ~]# yum list installed |grep openldap 
compat-openldap.i386                     2.3.43_2.2.29-12.el5_5.2      installed 
openldap.i386                            2.3.43-12.el5_5.2             installed 
openldap-clients.i386                    2.3.43-12.el5_5.2             installed 
openldap-devel.i386                      2.3.43-12.el5_5.2             installed 
openldap-servers.i386                    2.3.43-12.el5_5.2             installed 
openldap-servers-overlays.i386           2.3.43-12.el5_5.2             installed 
openldap-servers-sql.i386                2.3.43-12.el5_5.2             installed 
 
[root@ldapsrv ~]# ps -ef |grep ldap 
ldap      3554     1  0 21:51 ?        00:00:00 /usr/sbin/slapd -h ldap:/// -u ldap 
avahi     3777     1  0 21:51 ?        00:00:00 avahi-daemon: running [ldapsrv.local] 
[root@ldapsrv ~]# ldapsearch -x -b "dc=jacklan,dc=com" 
# extended LDIF 
# 
# LDAPv3 
# base <dc=jacklan,dc=com> with scope subtree 
# filter: (objectclass=*) 
# requesting: ALL 
# 
 
# jacklan.com 
dn: dc=jacklan,dc=com 
dc: jacklan 
description: LDAP Domain Admin 
objectClass: dcObject 
objectClass: organization 
o: jacklan, Inc. 
 
# People, jacklan.com 
dn: ou=People,dc=jacklan,dc=com 
ou: People 
description: Users of jacklan 
objectClass: organizationalUnit

from ldapclient1

PHP Code:



[root@ldapclient1 ~]# yum list installed |grep openldap 
openldap.i386                           2.3.43-3.el5                   installed 
openldap-clients.i386                   2.3.43-3.el5                   installed 
 
[root@ldapsrv]# cat  /etc/openldap/ldap.conf 
URI ldap://192.168.1.130/ 
BASE dc=jacklan,dc=com 
TLS_CACERTDIR /etc/openldap/cacerts  
 
[root@ldapsrv]# cat /etc/ldap.conf 
# The distinguished name of the search base. 
base dc=jacklan,dc=com 
. 
uri ldap://192.168.1.130/ 
ssl no 
tls_cacertdir /etc/openldap/cacerts

Can anyone help?

bathory · 09-28-2010, 07:49 AM

You can use either one of the following:

Code:

ldapsearch -x -b "dc=jacklan,dc=com" -H ldap://192.168.1.130
ldapsearch -x -b "dc=jacklan,dc=com" -h 192.168.1.130

jamrock · 09-28-2010, 01:15 PM

Make sure port 389 is open on both machines.

bathory · 09-28-2010, 01:42 PM

Quote:

Originally Posted by jamrock

Make sure port 389 is open on both machines.

Why does the client needs port 389 open?

jamrock · 09-28-2010, 08:11 PM

Quote:

Originally Posted by bathory

Why does the client needs port 389 open?

It depends on how the firewall is configured. On my servers I block all incoming and outgoing ports. I then specify the ports for incoming and outgoing traffic.

If the client is not configured to allow outgoing traffic with a destination port of 389, the packet will not leave the machine.

It is often useful to allow new packets out with a destination port of 389 and only established packets in. That way, only the client can initiate the exchange of ldap information.

On the other hand, some firewalls are configured to allow all new packets out and only established packets back in. With this configuration there is no need to specify that port 389 should be open on the client.

I prefer the more restrictive firewall rules.

JALITE · 09-29-2010, 09:34 AM

same error:

Quote:

[root@ldapclient1 ~]# ldapsearch -x -b "dc=jacklan,dc=com" -H ldap://192.168.1.130
ldap_bind: Can't contact LDAP server (-1)
[root@ldapclient1 ~]# ldapsearch -x -b "dc=jacklan,dc=com" -h 192.168.1.130
ldap_bind: Can't contact LDAP server (-1)

ldapsrv is listening port 389

Quote:

tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN

I don't see any established connection from ldapclient1 to ldapsrv which I expect to see.
Any other suggestion?

jamrock · 09-29-2010, 10:02 AM

I can see the configuration of the ldap client on ldapsrv.

Quote:

[root@ldapsrv]# cat /etc/openldap/ldap.conf
URI ldap://192.168.1.130/
BASE dc=jacklan,dc=com
TLS_CACERTDIR /etc/openldap/cacerts

I would like to see the configuration of the server's slapd.conf and the client's ldap.conf. Please post output from the following:

[root@ldapsrv]# cat /etc/openldap/slapd.conf

[root@ldapclient1]# cat /etc/openldap/ldap.conf

bathory · 09-29-2010, 11:27 AM

Hi,

Is the server is pingable from client, then it could be a firewall blocking access to port 389. Try

Code:

telnet 192.168.1.130 389

and see if you can connect

Regards

JALITE · 09-30-2010, 07:06 AM

Here are some output:
from client to server ping/telnet

Quote:

[root@ldapclient1 ~]# ping 192.168.1.130
PING 192.168.1.130 (192.168.1.130) 56(84) bytes of data.
64 bytes from 192.168.1.130: icmp_seq=1 ttl=64 time=0.346 ms
64 bytes from 192.168.1.130: icmp_seq=2 ttl=64 time=0.350 ms

[root@ldapclient1 ~]# telnet 192.168.1.130:389
192.168.1.130:389/telnet: Name or service not known

[root@ldapclient1 ~]# telnet 192.168.1.130
Trying 192.168.1.130...
telnet: connect to address 192.168.1.130: No route to host
telnet: Unable to connect to remote host: No route to host

Output of /etc/openldap/slapd.conf from ldapsrv:

Quote:

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema

# Allow LDAPv2 client connections. This is NOT the default.
allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org

pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args

# Load dynamic backend modules:
# modulepath /usr/lib/openldap

# Modules available in openldap-servers-overlays RPM package
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here
# moduleload accesslog.la
# moduleload auditlog.la
# moduleload denyop.la
# moduleload dyngroup.la
# moduleload dynlist.la
# moduleload lastmod.la
# moduleload pcache.la
# moduleload ppolicy.la
# moduleload refint.la
# moduleload retcode.la
# moduleload rwm.la
# moduleload smbk5pwd.la
# moduleload translucent.la
# moduleload unique.la
# moduleload valsort.la

# modules available in openldap-servers-sql RPM package:
# moduleload back_sql.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it. Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt
# TLSCertificateFile /etc/pki/tls/certs/slapd.pem
# TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
# by self write
# by users read
# by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database bdb
suffix "dc=jacklan,dc=com"
rootdn "cn=Manager,dc=jacklan,dc=com"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
# rootpw secret
rootpw {SSHA}ferIBvelONB8bU0+3ukqtNUDYLCaIhaA

# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /var/lib/ldap

# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,mail,surname,givenname eq,pres,sub
index uidNumber,gidNumber,loginShell eq,pres
index uid,memberUid eq,pres,sub
index nisMapName,nisMapEntry eq,pres,sub

# Replicas of this database
#replogfile /var/lib/ldap/openldap-master-replog
#replica host=ldap-1.example.com:389 starttls=critical
# bindmethod=sasl saslmech=GSSAPI
# authcId=host/ldap-master.example.com@EXAMPLE.COM

Output of /etc/openldap/ldap.conf from ldapclient1:

Quote:

[root@ldapclient1 ~]# cat /etc/openldap/ldap.conf
#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE dc=example, dc=com
#URI ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT 12
#TIMELIMIT 15
#DEREF never
URI ldap://192.168.1.130/
BASE dc=jacklan,dc=com
TLS_CACERTDIR /etc/openldap/cacerts

JALITE · 09-30-2010, 07:22 AM

found something interesting.
jacklan.com is a faked domain that I only use within my VMware network for testing ldap. So I added ldapsrv.jacklan.com to /etc/hosts file of ldapclient machine, /etc/nsswitch.conf use 'files dns' for 'hosts'.
From ldapclient pinging ldapsrv returns correct IP address, however, nslookup gave different IP for ldapsrc??

Quote:

[root@ldapclient1 ~]# netstat -nvr
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0

[root@ldapclient1 ~]# nslookup ldapsrv
Server: 211.29.152.116
Address: 211.29.152.116#53

Non-authoritative answer:
Name: ldapsrv
Address: 202.167.244.241
Name: ldapsrv
Address: 64.27.117.57

[root@ldapclient1 ~]# ping ldapsrv
PING ldapsrv.jacklan.com (192.168.1.130) 56(84) bytes of data.
64 bytes from ldapsrv.jacklan.com (192.168.1.130): icmp_seq=1 ttl=64 time=0.432 ms
64 bytes from ldapsrv.jacklan.com (192.168.1.130): icmp_seq=2 ttl=64 time=0.387 ms

[root@ldapclient1 ~]# cat /etc/hosts
# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 ldapclient1.jacklan.com ldapclient1 localhost.localdomain localhost
::1 localhost6.localdomain6 localhost6
192.168.1.130 ldapsrv.jacklan.com ldapsrv

Even that seems be a bit wired, but should not cause my problem here because in the client /etc/openldap/ldap.conf file, it use IP address instead for hostname, right?

bathory · 09-30-2010, 07:23 AM

Quote:

[root@ldapclient1 ~]# telnet 192.168.1.130:389
192.168.1.130:389/telnet: Name or service not known

You should leave a blank space between the IP and the port number, not use ":"

JALITE · 09-30-2010, 07:35 AM

Ok, problem solved. Indeed it's firewall problem. Port 389 in ldapsrv was not listed in the firewall trusted zone, or not opened!!
I thought ldapsrv is listening this port meaning it's open, maybe not the same. I can now successfully run ldapsearch from the client machine.
Thanks for all the great help!!

jamrock · 09-30-2010, 08:17 AM

In general, when machines can't communicate, start by checking the firewalls.

Please edit the title to show that the issue has been solved.

You may also want to do some research on ldap log levels. That is a useful way to trouble shoot connectivity issues.