Hi,
at the moment, ldap_int_sasl_bind() uses ldap_host_connected_to() to get a fully qualified host name that will be used as the server fqdn with the sasl client. This fqdn is acquired by ldap_host_connected_to() using a reverse DNS lookup. The code explains why this is done:
/* * do a reverse lookup on the addr to get the official hostname. * this is necessary for kerberos to work right, since the official * hostname is used as the kerberos instance. */
Using reverse DNS names has however always been problematic. The following comment is from the MIT code: (lib/krb5/os/sn2princ.c):
/* XXX: This is *so* bogus. There are several cases where this won't get us the canonical name of the host, but this is what we've trained people to expect. We'll probably fix it at some point, but let's try to preserve the current behavior and only shake things up once when it comes time to fix this lossage. */
To address this issue, a draft RFC has been written (draft-ietf-krb-wg-kerberos-referrals-09) that adds server-side name canonicalisation to Kerberos and therefore removes the need to use reverse DNS for this. This draft has been implemented in MIT Kerberos 1.6. The feature is enabled by default and if you want to use it you probably want to set "rdns = false" in [libdefaults] to disable canonicalisation based on reverse DNS.
Disabling these reverse DNS lookups however is not possible at the moment with the OpenLDAP client as explained above. I did a quick patch to have ldap_int_sasl_bind() use a value based on the LDAP option LDAP_OPT_HOST_NAME and that worked as expected.
Would you guys be interested in a patch that allows the disabling hostname canonicalisation based on reverse DNS? The patch would need to make this behaviour optional and non-default as some real workloads may break and also it would somehow need to handle LDAP URIs with multiple hosts.
Regards, Geert Jansen
--On Wednesday, October 24, 2007 2:04 AM +0200 Geert Jansen geert@boskant.nl wrote:
Would you guys be interested in a patch that allows the disabling hostname canonicalisation based on reverse DNS? The patch would need to make this behaviour optional and non-default as some real workloads may break and also it would somehow need to handle LDAP URIs with multiple hosts.
Does your patch work with if heimdal is being used as well? Because I've found MIT not to be worthwhile to compile the OpenLDAP server against for stability and throughput reasons.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount wrote:
Does your patch work with if heimdal is being used as well? Because I've found MIT not to be worthwhile to compile the OpenLDAP server against for stability and throughput reasons.
A patch against OpenLDAP 2.3 is attached below. It works fine with MIT but i have not tried it with Heimdal (i think it should work though). If I set "rdns = no" in [libdefaults] in the Kerberos configuration file, I get the following advantages:
- I can call "ldapsearch -h <host>" on a host that does not have a reverse DNS mapping. - I can call "ldapsearch -h <host>" on a host for which no domain to realm mapping exists locally, making use of server-side referrals (in my case with a Windows 2003 KDC).
The patch unconditionally disables hostname canonicalisation for the sasl client. In my view this should be OK, as the Kerberos library will do hostname canonicalisation anyway and therefore this step is redundant in OpenLDAP. But by not doing this in OpenLDAP, we add the possibility of the Kerberos library deciding to take another (or no) canonicalisation option. In my view, hostname canonicalisation is a Kerberos specific issue and therefore should be performed only in the Kerberos library.
I assume I need to create an issue tracker if I would want to submit this for inclusion? Also I will try to create versions of the patch for 2.4 and the trunk.
Regards, Geert
--On October 24, 2007 11:16:58 PM +0200 Geert Jansen geert@boskant.nl wrote:
I assume I need to create an issue tracker if I would want to submit this for inclusion? Also I will try to create versions of the patch for 2.4 and the trunk.
Yes. Note that what may be the final 2.3 release was tagged today (2.3.39) so you really should focus your efforts against 2.4.6 (tagged today) and HEAD.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration