Page MenuHomePhorge

Kolab webadmin connect to LDAPS server
Open, LowPublic


I was not able to make Kolab WAP work with LDAPS. Finally I got it working with the following setup:

ldap_uri = ldaps://

and modifying lib/Auth/LDAP.php file:

--- lib/Auth/LDAP.php.orig      2017-05-15 09:29:35.280000000 +0000
+++ lib/Auth/LDAP.php   2017-05-15 09:28:41.629000000 +0000
@@ -104,7 +104,7 @@ class LDAP extends Net_LDAP3 {
-        $this->config_set("host", $this->_ldap_server);
+        $this->config_set("host", $this->_ldap_uri);
         $this->config_set("port", $this->_ldap_port);
         $this->config_set("use_tls", $this->_ldap_scheme == 'tls');

It looks like PHP expects $scheme://$ldap_server in ldap_connect($host, $port) $host part.


Ticket Type

Event Timeline

machniak claimed this task.
machniak subscribed.

Fixed in 1b605db5f721f.

This could be more complicated than that. Unfortunately don't have enough time to investigate it deeper, but the above patch may influence how ldapsearch command is being issued by WAP. With the following patch I can login to WAP , but navigating inside WAP is inconsitent - sometimes shows user, sometimes not.

[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [INFO] (api) Vendor name is 389 Project
[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [DEBUG] (api) LDAP: Executing command: /usr/lib64/mozldap/ldapsearch -x -h ldaps://ldap.server:636 -p 636 -b 'ou=People,dc=domain,dc=tld' -s base -D 'cn=Directory Manager' -w * -J ' Manager' "(objectclass=*)" "*"
[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [DEBUG] (api) LDAP: Command output:array (
[19-May-2017 05:49:45 -0700](5t6r5rso35flk0urutm681uh35): [DEBUG] (api) Return code: 91

This ldapsearch command doesn't work from command line either:

ldap_simple_bind: Can't connect to the LDAP server - Invalid argument

I may have some time later to look deeper into what is happening.

We should try to use -H instead of -h and -b for ldapsearch.

That is what I thought, but:
-H display usage information
mozldap ldapsearch is a bit different from openldap ldap client tools.

It turns out mozldap ldapsearch tool uses nssdb for certificate verification and you can't turn it off. That means, that for mozldap ldapsearch you need to create nssdb databases and put ca certificate into this DB to make it work, otherwise you will get SSL initialization failed: error -8015 (unknown) error.
These are the steps I did:

Run mozldap ldap search with SSL enabled:

# /usr/lib64/mozldap/ldapsearch -x -h ldaphost -p 636 -b 'ou=People,dc=domain,dc=tld' -s base -D 'cn=Directory Manager' -w - -J ' Manager' '(objectclass=*)' -Z
SSL initialization failed: error -8015 (unknown)

Notice -Z at the end of commnd

Create NSSDB:

# certutil -N -d /path/to/nssdb

I used empty password for the database. Verify that it is created:

# certutil -L -d /path/to/nssdb

Certificate Nickname                                         Trust Attributes

Note: you can use . as /path/to/nssdb to create DB in the current directory.

Add CA certificate to the database. You will need a certificate in pem format to import:

# certutil -d . -A -n "Wildcard domain.tld certificate" -i /path/to/ -t 'C,,'

Verify that the certificate is in DB:

# certutil -L -d /path/to/nssdb

Certificate Nickname                                         Trust Attributes

Wildcard domain.tld certificate                               C,,

Run the mozldap ldapsearch tool again:

/usr/lib64/mozldap/ldapsearch -x -h ldaphost -p 636 -P /path/to/nssdb -b 'ou=People,dc=domain,dc=tld' -s base -D 'cn=Directory Manager' -w - -J ' Manager' '(objectclass=*)' -Z

Now the search works. It works even without -P if you run it being in the directory where you have created NSSDB, in other words it looks like default path to NSSDB (-P parameter) is ..
So it looks like for Kolab WAP to work with ldaps mozldap ldapsearch command should be use with -Z to enable SSL and with -P /path/to/nssdb and nssdb is created in /path/to/nssdb/ directory.

vanmeeuwen lowered the priority of this task from 60 to Normal.Mar 28 2019, 8:12 AM

I first needed to understand that the mozldap ldapsearch is only necessary for getting the effective rights. Reading and modifying the objects is done by php. While the php ldap libs use the system wide certificate storage the mozldap doesn't. So modifying wouldn't be the problem but kolab webadmin isn't able to get the aci rights for the ldap objects.

So we first need to configure the nssdb and import the root certificate of the ldap server certificate. This could be done in any directory. Since the 389-ds uses the /etc/dirsrv/slapd-INSTANCE/ for nssdb certificate path I used this directory too in my setup. Maybe it make sense to make this configurable.

My use case was a supplier -> consumer ldap replication between two hosts. While the supplier was outside the organisation the consumer is inside a private network. Both ldap servers communicate through tls. Now I wanted to have an kolab-webadmin instance inside the private network but using the read-write ldap supplier and not the consumer. Since ldap certificates are already configured it was obvious to use this nssdb.

For getting this working the user of the webserver has to have read access to the /etc/dirsrv/slapd-... path. Maybe this is not the best idea but sufficient in my use case:

adduser www-data dirsrv

At the end I got it working with these changes:

In php-net-ldap3:

root@ldap:~# diff -u /usr/share/php/Net/LDAP3.php.orig /usr/share/php/Net/LDAP3.php
--- /usr/share/php/Net/LDAP3.php.orig    2019-05-07 12:18:13.000000000 +0200
+++ /usr/share/php/Net/LDAP3.php    2019-08-13 17:42:20.191150384 +0200
@@ -777,14 +777,21 @@
             return null;

+    // we combine ldapuri and protocol to resolve
+        $ldapuri = preg_replace('|^[a-z]+://|i', '', $this->_current_host);
+        $nssdb = $this->config_get('nssdb');
+    //$nssdb = '/etc/dirsrv/slapd-ldap/';
+    if (preg_replace('|://.*|i', '', $this->_current_host) == 'ldaps') {
+        $ldap_uri = "-h $ldapuri -Z -P $nssdb";
+    } else {
+        $ldap_uri = "-h $ldapuri -p $port";
+    }
         $output = array();
         $command = Array(
-                '-h',
-                preg_replace('|^[a-z]+://|i', '', $this->_current_host),
-                '-p',
-                $this->config_get('port', 389),
+                $ldap_uri,
@@ -818,7 +825,7 @@

         // remove password from debug log
         $command_debug     = $command;
-        $command_debug[13] = '*';
+        $command_debug[10] = '*';

         $command       = implode(' ', $command);
         $command_debug = implode(' ', $command_debug);

and in kolab-webadmin - for configuration:

--- LDAP.php    2019-08-13 17:42:03.595050348 +0200
+++ LDAP.php.orig    2019-08-13 17:40:22.130412403 +0200
@@ -47,7 +47,6 @@

         $this->config_set("login_filter", $this->conf->get("kolab_wap", "login_filter"));
         $this->config_set("vlv", $this->conf->get("ldap", "vlv", Conf::AUTO));
-        $this->config_set("nssdb", $this->conf->get("nssdb"));

         // configure the cache
         $memcache_hosts = $this->conf->get('kolab_wap', 'memcache_hosts');

and the following config in the ldap section of kolab.conf:

ldap_uri = ldaps://
; for ldap tls-connection we need the cert path:
; and the webserver has to have read access
nssdb = /etc/dirsrv/slapd-ldap/
debug = true

machniak lowered the priority of this task from Normal to Low.Sep 27 2023, 3:06 PM

On PHP >= 7.3 we're not using the cli tool at all now. So, this shouldn't be a problem with recent installations.