LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (http://www.linuxquestions.org/questions/linux-server-73/)
-   -   openldap client fails to connect ldap server 'ldap_bind: Can't contact LDAP server' (http://www.linuxquestions.org/questions/linux-server-73/openldap-client-fails-to-connect-ldap-server-ldap_bind-cant-contact-ldap-server-834930/)

JALITE 09-28-2010 07:11 AM

openldap client fails to connect ldap server 'ldap_bind: Can't contact LDAP server'
 
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-daemonrunning [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
dndc=jacklan,dc=com
dc
jacklan
description
LDAP Domain Admin
objectClass
dcObject
objectClass
organization
o
jacklanInc.

# People, jacklan.com
dnou=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 (Post 4111683)
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 (Post 4111709)
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.


All times are GMT -5. The time now is 03:39 AM.