Bug 1469527 - [RFE] Use DNS SRV records for keystone V3 authentication
[RFE] Use DNS SRV records for keystone V3 authentication
Status: NEW
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python-ldap (Show other bugs)
7.3
Unspecified Unspecified
unspecified Severity unspecified
: pre-dev-freeze
: 7.5
Assigned To: Matthew Barnes
BaseOS QE Security Team
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-11 08:36 EDT by Ganesh Kadam
Modified: 2017-08-09 04:18 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ganesh Kadam 2017-07-11 08:36:15 EDT
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.
Comment 2 Nathan Kinder 2017-08-07 17:42:34 EDT
Keystone uses python-ldap for it's LDAP implementation, and it just passes the URI straight through.  The failover behavior that has been observed when a comma-separated list is passed is due to logic in python-ldap.

There is no LDAP standard that I am aware of where a suffix used as a URI without a host/port is supposed to use SRV records.  All that RFC 4516 says is the following:

      If no <host> is given, the client must have some a priori
      knowledge of an appropriate LDAP server to contact.

I believe that this is just a handy convenience behavior offered by the OpenLDAP tools (and potentially from certain calls in the OpenLDAP library).  This behavior would be nice to have in python-ldap as well.

Since python-ldap is shipped as a part of RHEL, this bug should be moved to be an RFE for RHEL instead of RH-OSP.  I am moving this to target RHEL so it can be evaluated as an RFE for a future RHEL release.

Note You need to log in before you can comment on or make changes to this bug.