Support LDAP server discovery via DNS SRV records

Bug #1733836 reported by Colleen Murphy on 2017-11-22
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Wishlist
Unassigned

Bug Description

When an organization has more than one LDAP server and a potentially large number of clients connecting to them, they may support automatic discovery of those servers by creating DNS SRV records for them. The overview of how this works is described here:

http://www.rjsystems.nl/en/2100-dns-discovery-openldap.php

When using OpenLDAP utilities like the ldapsearch command line tool, we can use syntax like this to discover an LDAP host and make queries against it:

ldapsearch -H ldap:///dc%3Dexample%2Cdc%3Dcom uid=ccolumbus

python-ldap does not support discovery this way. It interprets a URL like this as referring to a file on localhost. Based on this thread, it seems unlikely that python-ldap or libldap would be willing to support this:

https://mail.python.org/pipermail/python-ldap/2013q4/003298.html

Their concerns seem to be about this being a major change in behavior. It also poses a problem for TLS-secured hosts since we'd no longer be requesting the host directly by its CN, also mentioned in this thread:

http://python-ldap.python.narkive.com/27BmiEIr/connect-to-multiple-servers-for-failover#post6

We could implement this in keystone, as a wrapper around ldappool/python-ldap. It would come with the caveat that DNSSEC is necessary and that LDAPS/StartTLS might not work or you might have to add some weird alt names to your certificates.

It looks like RedHat has had this idea as well:

https://bugzilla.redhat.com/show_bug.cgi?id=1469527

In that report, Nathan suggests that this should be in python-ldap rather than keystone, but based on the above python-ldap thread I think that might be an uphill battle.

Thoughts?

Lance Bragstad (lbragstad) wrote :

This certainly sounds like it would be useful. I'd be curious to see what operators or users bite on this. Do you know who that would be?

tags: added: ldap
Colleen Murphy (krinkle) wrote :

> Do you know who that would be?

We have a customer with a large LDAP deployment. The maintenance for the LDAP infrastructure is handled by a different department, so they don't have control over when LDAP servers are rotated in or out. They ran into an issue where one or two were swapped out from under them and keystone started causing Gateway Timeouts because it was trying to reach missing LDAP servers in the sequence configured in keystone.conf. They could have avoided this by just pointing keystone at the SRV record that the other team keeps up to date when they swap out servers.

Adam Young (ayoung) wrote :

A change like that really should be tackled at the lowest level, and not ad-hoc by each of the consumers. If openldap client libraries support it, the python libraries should as well. But that is an argument for the python-ldap team. I'm not against enabling this for Keystone if you want to go ahead an write the code.

I think this would call for a spec, though, to walk through the design decisions.

Changed in keystone:
status: New → Triaged
Colleen Murphy (krinkle) on 2018-10-15
tags: added: foobar
tags: removed: foobar
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers