I have a vanilla Scientific Linux 6.6 install (essentially RHEL 6.6) which I am trying to set up as an LDAP server. I have installed openldap-servers and started slapd with service slapd start. This default creates come configuration files in /etc/openldap/slapd.d/ which, as I understand it is the newer config format.

To add a root user and password I created a file rootuser.ldif as (passwords changed of course):

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}n/y444ydfghRfgOzTGwh4A47Ih4Ek9fg

dn: olcDatabase={2}bdb,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}n/y444ydfghRfgOzTGwh4A47Ih4Ek9fg
replace: olcRootDN
olcRootDN: cn=admin,dc=example,dc=com
replace: olcSuffix
olcSuffix: dc=example,dc=com

and ran ldapmodify -a -Q -Y EXTERNAL -H ldapi:/// -f test.ldif (based on the answer at Basic openldap setup using slapd.d configuration) while logged in as root on the server.

This works and returns:

modifying entry "olcDatabase={0}config,cn=config"

modifying entry "olcDatabase={2}bdb,cn=config"

To check that it worked I can do ldapsearch -Y EXTERNAL -H ldapi:/// -b "olcDatabase={2}bdb,cn=config" olcRootDN which returns:

SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
# extended LDIF
# LDAPv3
# base <olcDatabase={2}bdb,cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: olcRootDN 

# {2}bdb, config
dn: olcDatabase={2}bdb,cn=config
olcRootDN: cn=admin,dc=example,dc=com

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

However, if I want to search using the ldap:// protocol (as I will need to when connecting remotely from clients or to connect phpldapadmin) I get an error. Running ldapsearch -D "cn=admin,dc=example,dc=com" -W and entering the password as earlier just gives:

ldap_result: Can't contact LDAP server (-1)

Adding on -d5 -v to the ldapsearch command gives a whole load of output:

ldap_initialize( <DEFAULT> )
Enter LDAP Password: 
ldap_new_connection 1 1 0
ldap_connect_to_host: TCP localhost:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying ::1 389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
attempting to connect: 
connect success
ldap_open_defconn: successful
ber_scanf fmt ({it) ber:
ber_scanf fmt ({i) ber:
ber_flush2: 78 bytes to sd 3
ldap_result ld 0x7bc270 msgid 1
wait4msg ld 0x7bc270 msgid 1 (infinite timeout)
wait4msg continue ld 0x7bc270 msgid 1 all 1
** ld 0x7bc270 Connections:
* host: localhost  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Fri Feb  6 13:29:49 2015

** ld 0x7bc270 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
  ld 0x7bc270 request count 1 (abandoned 0)
** ld 0x7bc270 Response Queue:
  ld 0x7bc270 response count 0
ldap_chkResponseList ld 0x7bc270 msgid 1 all 1
ldap_chkResponseList returns ld 0x7bc270 NULL
read1msg: ld 0x7bc270 msgid 1 all 1
ldap_result: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed

I'm pretty sure that the server is running on port 389 as telnet localhost 389 gives:

Trying ::1...
Connected to localhost.
Escape character is '^]'.
Connection closed by foreign host.

If I run slapd manually and set -d-1 then I see the following output when I try to access it through ldap://

54d4dfec daemon: activity on 1 descriptor
54d4dfec daemon: activity on:54d4dfec 
54d4dfec slap_listener_activate(7): 
54d4dfec daemon: epoll: listen=7 busy
54d4dfec daemon: epoll: listen=8 active_threads=0 tvp=zero
54d4dfec >>> slap_listener(ldap:///)
54d4dfec daemon: listen=7, new connection on 12
54d4dfec daemon: activity on 1 descriptor
54d4dfec daemon: activity on:54d4dfec 
54d4dfec daemon: epoll: listen=7 active_threads=0 tvp=zero
54d4dfec daemon: epoll: listen=8 active_threads=0 tvp=zero
54d4dfec fd=12 DENIED from unknown (
54d4dfec daemon: closing 12

Is there perhaps some ACL that I need to set up to allow the olcRootDN to be allowed to query the database?


It seems that the problem as being caused by /etc/hosts.allow. I added


to the end of that file and I am now getting "Invalid credentials" error instead which is likely a different problem.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.