Re: ldap_int_sasl_bind() and canonical Kerberos names

[Donn Cave <donn@u.washington.edu>]

> --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