Can't contact LDAP server remotely from Mac

Question

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.

Answer 1

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 the LDAP port and swistch to TLS 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.

Answer 2

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 port 389. 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, since ldaps://server.com:389 is already a secure connection, StartTLS cannot be used. Your server should accept connections from clear-text clients on ldap://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 on ldap://server.com:636.