Bug 1469527

Description of problem:

IHAC, looking forward to use DNS SRV records with their ldap servers. 


Cu is using Keystone v3 and domains for LDAP authentication as mentioned in below KB article:
~~~
https://access.redhat.com/solutions/2988661
~~~

As there are multiple LDAP servers Cu have used the following syntax in the ldap-environment.yaml at the moment. That works pretty well. The problem that arises with that configuration is that all connections go to the server "quant9" first as per Cu. 

==== snip =====
parameter_defaults:
  ControllerExtraConfig:
    keystone::using_domain_config: true
    tripleoldap::ldap:
      bioquant:
        url: ldaps://quant9.x.x.x:636,ldaps://quant10.x..x:636
        suffix: DC=bioquant,DC=uni-heidelberg,DC=de
        user_tree_dn: ou=people,DC=bioquant,DC=uni-heidelberg,DC=de
        user_objectclass: person
==== snip =====


Hence they want to use DNS SRV records with both servers. But the Python module responsible for the LDAP connection does not seem to support LDAP-URLs regarding RFC 4516.
~~~
https://tools.ietf.org/html/rfc4516 
~~~


When using ldapsearch to verify that the URL is well formed, it works as expected:
~~~
[root@ospd-stage ~]# ldapsearch -H ldaps:///dc%3Dbioquant%2Cdc%3Duni%2Dheidelberg%2Cdc%3Dde -x -b ou=people,DC=bioquant,DC=uni-heidelberg,DC=de| head # extended LDIF # # LDAPv3 # base <ou=people,DC=bioquant,DC=uni-heidelberg,DC=de> with scope subtree # filter: (objectclass=*) # requesting: ALL #

# People, bioquant.uni-heidelberg.de
dn: ou=People, dc=bioquant,dc=uni-heidelberg,dc=de
~~~

If you try the same syntax for the URL in the keystone/domains/*conf the module tries to connect to that URL directly, it fails obviously, instead of asking the DNS for A (or AAAA) records for _ldap._tcp.bioquant.uni-heidelberg.de:

~~~
2017-06-22 08:58:05.075 1011689 DEBUG keystone.identity.backends.ldap.common [req-7fb247ef-bb65-4f9c-b957-1e3f4385950c 3aa594d0861241e2a95c542c7685a650 4ffe91483fe34912957e54b63507f36d - default default] LDAP init: url=ldaps:///dc%3Dbioquant%2Cdc%3Duni-heidelberg%2Cdc%3Dde _common_ldap_initialization /usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py:574
2017-06-22 08:58:05.076 1011689 DEBUG keystone.identity.backends.ldap.common [req-7fb247ef-bb65-4f9c-b957-1e3f4385950c 3aa594d0861241e2a95c542c7685a650 4ffe91483fe34912957e54b63507f36d - default default] LDAP init: use_tls=False tls_cacertfile=/etc/pki/ldap/ca.crt tls_cacertdir=None tls_req_cert=2 tls_avail=1 _common_ldap_initialization /usr/lib/python2.7/site-packages/keystone/identity/backends/ldap/common.py:578
~~~

Version-Release number of selected component (if applicable):

RHOSP10, Keystone


Cu has raised RFE for this.