[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ldap_int_sasl_bind() and canonical Kerberos names

--On October 24, 2007 10:42:43 PM +0100 Simon Wilkinson <simon@sxw.org.uk> wrote:

The patch unconditionally disables hostname canonicalisation for the sasl client.

I think this will break GSSAPI connections to LDAP servers that are behind DNS round robin style load balancers.

Assume that you have 'ldap' that is a CNAME for ldap-1 and ldap2. The
LDAP library initiates a connection to 'ldap', and DNS points it to
'ldap-1'. Providing you ask SASL to set up a connection to 'ldap-1',
you're fine (this is what the code does at the moment). However, if you
ask the SASL library for a connection to 'ldap' (this is what your change
does, as far as I can tell), and the library does a canonicalisation step
(as most Kerberos implementations currently do), it will get 'ldap-2'
back from the DNS. So, you end up trying to negotiate a SASL connection
with 'ldap-2', when you're actually connected to 'ldap-1'. This tends not
to work.

I concur, I was just writing to say the same. From what I see, the proposed change will pass the name from the ldaps: URL to SASL (_sasl_conn_init serverFQDN), and I assume this name is used in the GSS Kerberos5 authentication request. It will indeed be canonicalized by the MIT library, and as described above that's exactly why it needs to be determined from the connection address, in an environment with dynamic DNS data and MIT Kerberos authentication. Other environments might benefit from this change, but it would have to be optional.

	Donn Cave, donn@u.washington.edu