I try to setup LDAPS authentification on Zabbix 2.4 but it's not working. Here is the infos on my configuration :

  • OS : Debian
  • PHP packages installed : libapache2-mod-php5 php-pear php5 php5-cli php5-common php5-curl php5-gd php5-imagick php5-json php5-ldap php5-mysqlnd php5-pgsql php5-readline php5-sasl zabbix-frontend-php

  • This command is working :

ldapsearch -H ldaps://ldaps.mptest.be:636 -D cn=reader,dc=antidot,dc=prv -W -b ou=people,dc=antidot,dc=prv

Same URI, OU, login, password in the Authentification LDAP setup page on zabbix, I have this :

ldap_bind(): Unable to bind to server: Can't contact LDAP server

[authentication.php:120 → CLdapAuthValidator->validate() → CLdap->checkPass() → ldap_bind() in /usr/share/zabbix/include/classes/ldap/CLdap.php:112] LDAP: cannot bind by given Bind DN. Login name or password is incorrect!

Here is the content of /etc/ldap/ldap.conf: TLS_REQCERT allow BASE dc=antidot,dc=prv URI ldaps://ldap.mptest.be TLS_CACERTDIR /etc/ssl/mptest/wildcard_mptest_be.ca

(Authentification without SSL, on port 386 is not possible)

  • What version of Debian? Have you checked connectivity without SSL (be careful with this, change password immediately after if you do)? Tell us also contents of /etc/ldap.conf. – sam_pan_mariusz Aug 24 '15 at 7:31
  • Thanks for your reply, I edit the main post with the ldap config. unfortunately, Ldap on port 386 without SSL is not possible. – Nico_Melotte Aug 24 '15 at 7:57
  • Everything seems to be fine here. Are there any per-process or per-user firewall rules? Have you tested LDAPS connectivity with another, simple PHP script? And have you considered authenticating in httpd (Apache?) and passing REMOTE_USER to application? Zabbix works that way in my workplace (although with Kerberos, not LDAP, as we prefer having SSO). – sam_pan_mariusz Aug 24 '15 at 8:52
  • I did try a test PHP : code<?php $handle = ldap_connect('ldaps://ldaps.mptest.be',636); $bind = ldap_bind($handle, 'cn=reader,dc=antidot,dc=prv', 'reader'); echo "TEST BIND"; if ($bind) { if (ldap_get_option($handle, LDAP_OPT_DIAGNOSTIC_MESSAGE, $extended_error)) { echo "Error Binding to LDAP: $extended_error"; } else { echo "Error Binding to LDAP: No additional information is available."; } } else { echo "not binding"; } ?>code – Nico_Melotte Aug 24 '15 at 8:55
  • And i have a dokuwiki page that is using that LDAPS server but in anoymous – Nico_Melotte Aug 24 '15 at 9:04

This is what works on Ubuntu 14.04. Debian based system should be the same:


  • Welcome to Server Fault! Whilst this may theoretically answer the question, it would be preferable to include the essential parts of the answer here, and provide the link for reference. – Gerald Schneider Jul 14 '17 at 17:25
  • The tip in the answer is really good, and I think that this was the site that also helped me getting onto the right track. Good input, thank you @jouflux. – hargut Jan 4 at 23:04

I resolved this problem by visiting the Zabbix web interface, then going to Administration -> Authentication -> LDAP and changing the LDAP host parameter from hostname (e.g. ldap.example.com) to its IP address (e.g.,


PHP's LDAP is, to be frank, pure crap. Some time ago I did also struggle with Zabbix and LDAPS. You can do everything 100% correct, but it will still fail. So, no worries, the issue here is not on your side.

To get that working you have to disable TLS/SSL certificate validation in OpenLDAP. PHP's LDAP uses the OpenLDAP libraries, and therefore /etc/openldap/ldap.conf or ~/.ldaprc are loaded and matter. (This can be seen, using an example PHP LDAP query and running that with strace -e trace=open php example.php). The problem here seems to be located in the area of PHPs usage of the OpenLDAP libraries, some missing/wrong/not implemented calls for successful TLS certificate validation. Fixing that would involve patching PHP.

TLS_REQCERT never should be the parameter needed to get that going. The URL and OU/DC settings in ldap.conf should not be relevant as they are provided from the Zabbix configuration. I strongly suggest to modify that in ~/.ldaprc of your webservers home directory, to not affect any other application using LDAPS.

This solution is not a good one, but still better than falling back to unencrypted LDAP. And just to clarify, I tried it with manually placing CACerts for OpenLDAP, regenerating the cert cache and setting TLS_REQCERT to always. This worked fine using e.g. ldapsearch (uses the same librarie as PHP), but still failed with PHPs LDAP feature. So this attempt will likely be a waste of time. I did not try to place the client certificate and use TLS_KEY/TLS_CERT as indicated in the answer from @jouflux. If that works it would be a better solution.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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