RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1469527 - [RFE] Use DNS SRV records for keystone V3 authentication
Summary: [RFE] Use DNS SRV records for keystone V3 authentication
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: python-ldap
Version: 7.3
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: pre-dev-freeze
: 7.5
Assignee: Aviv Guetta
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks: 1477664
TreeView+ depends on / blocked
 
Reported: 2017-07-11 12:36 UTC by Ganesh Kadam
Modified: 2023-09-07 18:54 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-14 15:01:28 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github https://github.com/python-ldap python-ldap issues 248 0 None None None 2018-10-15 11:27:58 UTC
Red Hat Issue Tracker FREEIPA-7523 0 None None None 2021-12-10 15:19:48 UTC

Description Ganesh Kadam 2017-07-11 12:36:15 UTC 
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 21:42:34 UTC 
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.
Comment 8 Aviv Guetta 2018-07-29 07:08:47 UTC 
Hi,
Another kind follow-up for update on this BZ.


Aviv
Comment 9 Matthew Barnes 2018-09-17 13:05:27 UTC 
This request needs to be moved upstream or it's going to continue languishing here since apparently python-ldap developers don't watch this space.

https://github.com/python-ldap/python-ldap/issues

I only maintain the RPM, I don't develop this software.
Comment 10 Aviv Guetta 2018-10-15 11:27:59 UTC 
Hi,
I opened a new request to 'python-ldap' upstream[1].


Regards,
Aviv


[1] https://github.com/python-ldap/python-ldap/issues/248
Comment 15 Martin Kosek 2019-03-14 15:01:28 UTC 
Given that this proposal was rejected in both OpenLDAP upstream (kudos to Nathan Kinder for finding that link):
https://mail.python.org/pipermail/python-ldap/2013q4/003298.html
and also python-ldap upstream:
https://github.com/python-ldap/python-ldap/issues/248
I do not think it makes sense keeping it in downstream as well. The ask would need to be solved in another way.

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