Connecting Docker container to corporate LDAP server through SSL

I need to connect a Docker container to a corporate LDAP server.

The container’s purpose is to authenticate users against the company’s LDAP server.

  • Docker Container's network interface in promiscuous mode
  • Does a restart in a Dockerfile make sense?
  • Iptables to forward remote port to local port for local access
  • Why is docker volume create and rm not symmetrical?
  • ps command cannot connect to the docker daemon even after adding user to docker group [duplicate]
  • How to run services on startup in docker container
  • The container can query the server in “anonymous” mode flawlessly. The problem is when I try to authenticate. The server requires for the credentials to be transmitted confidentially. That is, through SSL/TLS.

    What’s interesting is that, on my Ubuntu host machine, I am able to query the server and authenticate against it. So, this works on my host but not on the container

    ldapsearch -x -D "uid=<ACCOUNT>,ou=People,o=hp.com" -W -H ldaps://<LDAP DOMAIN> -b "o=hp.com" -s sub 'uid=*'
    

    The containers can query the server anonymously (without SSL). So this works in the container:

    ldapsearch -d8 -x -H ldaps://<LDAP DOMAIN> -b "o=hp.com" -s sub 'uid=*'
    

    As does this:

    curl "ldap://<LDAP DOMAIN>/o=hp.com?cn?sub?(sn=rosado)"
    

    Now, I know for sure this is a problem with SSL because inside the container…

    1)I am able to connect to the LDAP server anonymously (because anonymous users don’t need to communicate confidentially. Therefore, they don’t need SSL).

    2)I get the following report when running ldapsearch in debug mode:

    ldapsearch -x -D "uid=<ACCOUNT>,ou=People,o=hp.com" -W -H ldaps://<LDAP DOMAIN> -b "o=hp.com" -s sub 'uid=*
    

    Debug Output:

    TLS: can't connect: (unknown error code).    ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
    

    Some of the things I’ve tried include:

    -Mounting the certificate from my host to my container. Placing it up /usr/local/share/ca-certificates/ and doing update-ca-certificates.

    -Using the openssl client in the container to make sure the connection can be established openssl s_client -connect <LDAP DOMAIN>:<PORT>. Here’s the output:

    CONNECTED(00000003)
    depth=1 O = hp.com, OU = IT Infrastructure, C = US, O = Hewlett-Packard Company, CN = <CORP INFO> Class 2 Certification Authority
    verify error:num=19:self signed certificate in certificate chain
    verify return:0
    ---
    Certificate chain
     <CORP INFO>
    ---
    Server certificate
    -----BEGIN CERTIFICATE-----
    <CORP INFO>
    
        Start Time: 1426872988
        Timeout   : 300 (sec)
        Verify return code: 19 (self signed certificate in certificate chain)

  • API server failed to start up
  • docker: how-to install elasticsearch delete-by-query
  • Does the process inside of the docker image still need to be managed?
  • Docker Remote API on windows native
  • “network not manually attachable” when running one-off command against docker swarm network
  • Increasing docker volume size using docker-compose
  • One Solution collect form web for “Connecting Docker container to corporate LDAP server through SSL”

    SSL/TLS connections usually fail for two reasons: protocol mismatch or trust issue.

    Protocol mismatch can be diagnosed using network protocol analyzer such as Wireshark or by turning on debugging of the client (use -d 65535 parameter to ldapsearch).

    Trust issues should be also visible in the debug output. But also check the ldap.conf‘s TLS_CACERT or TLS_CACERTDIR parameter that points to file or directory with all the trusted CA’s. Make sure that the ones in the docker container are equivalent to the ones on the host machine.

    While you’re at it check that the openldap version and the underlying SSL/TLS implementation versions (openldap could be using NSS, GnuTLS or OpenSSL) are the same in the docker container and on the host machine.

    Docker will be the best open platform for developers and sysadmins to build, ship, and run distributed applications.