Kolab webadmin connect to LDAPS server
Open, LowPublic
Actions

Assigned To

Authored By

	adomaitis
	May 15 2017, 11:34 AM

Description

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

[ldap]
ldap_uri = ldaps://pao1.it.fsi.io

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.

Details

Ticket Type: Task

Related Objects

Mentioned In: rWAP1b605db5f721: Fix ldaps:// connections (T2388)
Mentioned Here: rWAP1b605db5f721: Fix ldaps:// connections (T2388)

Event Timeline

adomaitis created this task.May 15 2017, 11:34 AM

machniak mentioned this in rWAP1b605db5f721: Fix ldaps:// connections (T2388).May 15 2017, 12:31 PM

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 '1.3.6.1.4.1.42.2.27.9.5.2:true:dn:cn=Directory 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 '1.3.6.1.4.1.42.2.27.9.5.2:true:dn:cn=Directory 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
                                                             SSL,S/MIME,JAR/XPI

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/domain.tld.ca.crt -t 'C,,'

Verify that the certificate is in DB:

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

Certificate Nickname                                         Trust Attributes
                                                             SSL,S/MIME,JAR/XPI

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 '1.3.6.1.4.1.42.2.27.9.5.2:true:dn:cn=Directory 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.

pasik subscribed.Nov 25 2017, 2:31 PM

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 https://git.kolab.org/T2388
+        $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(
                 $moz_ldapsearch,
                 '-x',
-                '-h',
-                preg_replace('|^[a-z]+://|i', '', $this->_current_host),
-                '-p',
-                $this->config_get('port', 389),
+                $ldap_uri,
                 '-b',
                 escapeshellarg($entry_dn),
                 '-s',
@@ -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]
ldap_uri = ldaps://ldap.example.org:636
; for ldap tls-connection we need the cert path:
; and the webserver has to have read access
nssdb = /etc/dirsrv/slapd-ldap/
debug = true

....

beat.rubischon subscribed.Aug 20 2019, 4:23 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.

Kolab webadmin connect to LDAPS serverOpen, LowPublicActions