Public bug reported: 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? ** Affects: keystone Importance: Wishlist Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1733836 Title: Support LDAP server discovery via DNS SRV records Status in OpenStack Identity (keystone): New 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? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1733836/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
