[Date Prev][Date Next]
Re: ldap_int_sasl_bind() and canonical Kerberos names
--On October 24, 2007 10:42:43 PM +0100 Simon Wilkinson
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,
ask the SASL library for a connection to 'ldap' (this is what your
does, as far as I can tell), and the library does a
(as most Kerberos implementations currently do), it will get 'ldap-2'
back from the DNS. So, you end up trying to negotiate a SASL
with 'ldap-2', when you're actually connected to 'ldap-1'. This
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, email@example.com