Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
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.
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.
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.