Hide Forgot
Description of problem: When parsing an ldap.conf that contains a host and port definition the nss_ldap do_add_hosts function always creates a URI starting with "ldap://" regardless of SSL being enabled. Within the libldap library, this has the effect of setting ldap_url_desc->lud_scheme to "ldap" instead of "ldaps" even when SSL is enabled. The actual connection is done over SSL, but the complication is when the response includes an "ldaps://..." referral to the same server:port, the libldap library considers this to be a different scheme ("ldaps" vs. "ldap") and opens new connections for each referral lookup instead of reusing a persistent connection. Version-Release number of selected component (if applicable): nss_ldap-253-42.el5 How reproducible: Always Steps to Reproduce: 1. Create an ldap.conf containing only: host hostname port 1234 ssl on debug 1 2. Run a "getent passwd" 3. Observe url from debug line: "ldap_url_parse_ext(ldap://hostname:1234)" Actual results: libldap reports url of "ldap://hostname:1234" Expected results: With ssl on, this should be "ldaps://hostname:1234" Additional info: According to the nss_ldap manpage: "uri <ldap[is]://[name[:port]] ...> For LDAP client libraries that support it, specifies the URI(s) of the LDAP server(s) to connect to. The URI scheme may be ldap, ldapi, or ldaps, specifying LDAP over TCP, IPC and SSL respectively. If applicable, a port number can be specified; the default port number for the selected protocol is used if omitted. This option takes precedence over the host option; it is not possible to combine the two." The URI that nss_ldap creates itself should conform to this definition by using "ldaps://" when SSL is enabled.
I've been thinking about this request some more and I'm not sure I agree anymore. The referral should be specifying the exact URI the client should be following. So if the user needs all the URIs to be encrypted, they must be specified as encrypted in the referrals. I would suggest that the customer uses TLS instead of ldaps://. I'm pretty certain (although I haven't tested this scenario) that referrals also use TLS. Actually, I think this case is a nice argument in favor of using TLS, not ldaps:// because when using TLS, there's no ambiguity if both ldap:// and ldaps:// URIs are used. In short, I think this is a NOTABUG. The correct way is to use TLS.
That is not exactly the case we are hitting here. The referrals *are* in the format "ldaps://..." the problem is the initial connection as parsed from ldap.conf. If you specify host, port, and ssl on separately in the ldap.conf, it builds a "ldap://host:port" URI instead of the expected "ldaps://host:port". So when the referral comes in as ldaps, the schema does not match, and the library can't reuse the existing connection. The code always sets ldap_url_desc->lud_scheme to "ldap". We think this should be "ldaps" when ssl is turned on.
Thank you for the explanation. I agree (again :-)).
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux release for currently deployed products. This request is not yet committed for inclusion in a release.
Created attachment 600289 [details] A proposed patch This patch changes configuration loading such that the host names are just tracked first and then, after the config file is processes and we know the value of the "ssl" option, added to the list of known URIs with either ldap:// or ldaps://.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0085.html