I have an OpenLDAP server in my server environment and I have another two servers[two LDAP clients] which I have configured with my LDAP server for user login. my LDAP server is only supporting LDAPS (port: 636) and it does not support LDAP (port: 389). But my problem is, from one of my LDAP clients I removed the "tls_cacertdir" directive from the nslcd.conf and allowed users to login into that particular server [server is configured to communicate with LDAP server via LDAPS (port: 636). normal LDAP (port: 389) is disabled]. Surprisingly that server is allowing users to login into the server. but the same time I removed the "tls_cacertdir" from the other LDAP client, then it was not allowing users to log in to the server and there was an error saying that can't connect into the LDAP server. Now I'm a little bit confused actually why I'm experiencing two different behaviours in these two LDAP clients. Furthermore, I'm worried now, because now I doubt that actually LDAP is communicating over LDAPS or not. Can someone please explain to me why is this happening?

Server A : [this LDAP client will reject user login when I remove "tls_cacertdir" directive from the nslcd.conf]
openldap-clients.x86_64            2.4.44-5.el7
nss-pam-ldapd.x86_64               0.8.13-8.el7

Server B : [this LDAP client will NOT reject user login when I remove "tls_cacertdir" directive from the nslcd.conf]
openldap-clients.x86_64       2.4.44-21.el7_6
nss-pam-ldapd.x86_64          0.8.13-16.el7_6.1

In some places I read that when slapd is using GnuTLS, "tls_cacertdir" is ignored. but then I checked the slapd [refer the below dump]. it was not using the GnuTLS. Then I just removed "/etc/pki/tls" directory and tried to login. then "server B" did not allow users to login. LDAPS connection failed. Can someone please explain why is this happening?

[root@xxx-xxx-xx ~]$ ldd /usr/sbin/slapd
    linux-vdso.so.1 =>  (0x00007ffc7ed3a000)
    libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f58caea9000)
    liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f58cac9a000)
    libdb-5.3.so => /lib64/libdb-5.3.so (0x00007f58ca8dc000)
    libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f58ca6bf000)
    libnss3.so => /lib64/libnss3.so (0x00007f58ca392000)
    libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f58ca176000)
    libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f58c9f3f000)
    libslapi-2.4.so.2 => /lib64/libslapi-2.4.so.2 (0x00007f58c9d1f000)
    libltdl.so.7 => /lib64/libltdl.so.7 (0x00007f58c9b15000)
    libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f58c990a000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f58c953d000)
    libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f58c9324000)
    libssl3.so => /lib64/libssl3.so (0x00007f58c90d2000)
    libsmime3.so => /lib64/libsmime3.so (0x00007f58c8eab000)
    libnssutil3.so => /lib64/libnssutil3.so (0x00007f58c8c7c000)
    libplds4.so => /lib64/libplds4.so (0x00007f58c8a78000)
    libplc4.so => /lib64/libplc4.so (0x00007f58c8873000)
    libnspr4.so => /lib64/libnspr4.so (0x00007f58c8635000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f58c8431000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f58cb573000)
    libfreebl3.so => /lib64/libfreebl3.so (0x00007f58c822e000)
    libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f58c8014000)
    librt.so.1 => /lib64/librt.so.1 (0x00007f58c7e0c000)

You did not tell us which Linux distribution you're using. But most ship with a package called ca-certificates (or similar name) which has a tool to build a system-wide trust store (CA dir and CA bundle file). This gets used as default trust store by libldap if nothing else is specified.

Therefore I suspect that your two systems had different default trust stores.

  • Sorry, I missed it. all my servers are running on RHEL 7.x. If I am more specific: Server A - RHEL 7.3 Server B - RHEL 7.6 – yello_flash Jul 19 '19 at 4:23
  • But you know, this is not working with sudo-ldap.conf. in order to work with sudoers. I had to specifically include the CA directory in sudo-ldap.conf [tls_cacertfile directive]. otherwise, it failed. – yello_flash Jul 19 '19 at 4:28

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.