LDAP connection fails with multiple servers using STARTTLS

[terra-nova]

I am configuring LDAP authentication with multiple servers (4 DCs in a ActiveDirectory domain). I can specify multiple servers separated with a space when using either LDAPS or unencrypted LDAP, but validation fails when selecting STARTTLS.

Validation with STARTTLS works with any individual DC, but not with any number greater than one.

I guess the problem is with how hostnames are passed down to the underlying OpenLDAP library. The problem goes away if I manually prepend "ldap://" to the hostname of each server.

For example, the following ldapsearch command succeeds using STARTTLS:

$ ldapsearch -D 'cn=...' -W -H 'ldap://dc1... ldap://dc2...'' -b 'ou=...' -x '(objectClass=*)' -ZZ
...
success!

But the following (without ldap:// URI) does not:

$ ldapsearch -D 'cn=...' -W -H 'dc1... dc2...'' -b 'ou=...' -x '(objectClass=*)' -ZZ
...
FAILURE

This seems somewhat similiar, but not quite identical, to issues #2906, #2818

Exhibit A: Working config with LDAPS

Exhibit B: Exact same config with STARTTLS

Expected Behavior

Identical behaviour with either STARTTLS or LDAPS.

Current Behavior

The exact same configuration that works with LDAP or LDAPS does not work with STARTTLS.

Possible Solution

Manually prepending each server hostname with ldap:// works around the issue, but this should really be done automatically by Icingaweb2 (as is already the case with LDAPS).

Steps to Reproduce (for bugs)

Context

Your Environment

• Icinga Web 2 version and modules (System - About): 2.6.2
• Version used (icinga2 --version): 2.10.2
• Operating System and version: CentOS 7.5 x64
• Enabled features (icinga2 feature list):
• Config validation (icinga2 daemon -C):
• If you run multiple Icinga 2 instances, the zones.conf file (or icinga2 object list --type Endpoint and icinga2 object list --type Zone) from all affected nodes.

[nilmerg]

Hi, thanks for the report.

I fear that the statement in PHP's documentation of ldap_connect really only talks about LDAP-URIs in the sense of ldap://some.where and not just some.where:

You can also provide multiple LDAP-URIs separated by a space as one string

At least this is what your description sounds like. I'll investigate this but it smells like a bug already.