I'm trying to configure a LDAP server with some basic security parameters, including TLS and required authenticated binding.
I have started the server, and can access it from localhost with the command:
ldapsearch -x -b 'dc=server,dc=com' 'objectclass=*' -W -D 'cn=manager,dc=server,dc=com' -H ldaps://server.com:389
When I try the same command remotely, from my computer, I get the following error message:
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
I don't know why this happens, I can ping my server and there is currently no firewall.
slapd
is launched with -h ldaps://server.com:389/
DNS server is configured in a basic way on the same server, with only a A record.
Do you have any idea ?
EDIT
I've tested from another workstation, on arch-linux, and it works!
On both computer I have TLS_REQCERT allow
in /etc/openldap/ldap.conf
, so that shouldn't be a certificate problem no?
The workstation on which the ldap query doesn't work is on Mac OS X, if that have any importance.
Some output:
Telnet:
telnet server.com 389
Trying w.x.y.z...
Connected to server.com.
Escape character is '^]'.
Iptables:
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Netstat:
sudo netstat -lnt | grep 389
tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN
tcp6 0 0 :::389 :::* LISTEN
I've tested without any security parameters, and I have the same result.
I would consider using the standard port. Start with
-h ldap:///
. LDAP supports startTLS and can be easily configured to require TLS before passing sensitive information.Telnet can be used to determine if you can reach the server. Try the command
telnet server.com ldap
. This should connect if the server address is correct.On the server you can check to ensure that LDAP is bound to the external address using the command
netstat -lnt | grep 389
. This will show which address you are listening on.Once you have LDAP working without TLS enable startTLS and/or add
ldaps:///
to your startup.You can use the option
security update_ssf=16 simple_bind=16
to require TLS for these operations. Clients can then connect to theLDAP
port and swistch toTLS
using the startTLS operation.EDIT: Using debug on the client and/or server can be helpful in determining where the connection is failing. Add
-d -1
to the command line to debug everything. The debug switch accepts a bitmap of debug flags for various subsystems.-d ?
will list them and their values. Once you know a subsystem is working, you can stop debugging and focus on other subsystems.Starting debugging with the client is easiest, but it may be necessary to do some debugging on the server. If you are logging via syslog, it is helpful to have a debug log file where you can examine the debug output.
When you use an LDAP URL in the form
ldaps://server.com:389
, the server will expect that SSL negotiation will take place when a client connects on port389
. StartTLS cannot be used on an existing SSL connection: StartTLS 'converts' (perhaps promotes is a better word) an insecure connection to a secure connection, therefore, sinceldaps://server.com:389
is already a secure connection, StartTLS cannot be used. Your server should accept connections from clear-text clients onldap://server.com:389
and reject any client connections that do not immediately promote using StartTLS - if your server product cannot immediately reject unsecure client connections, you should choose product that cat. If an SSL endpoint is also required, the server should listen for secure client connections onldap://server.com:636
.