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

Re: ldap_int_sasl_bind() and canonical Kerberos names

Hash: SHA1


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

Thanks for the explanation and indeed I see that my patch would break
this use case. I have come to the conclusion that one of the two
reasons why I looked into this patch (do not keep realm data on the
local system) is actually a problem that has nothing to do with
canonicalisation. Realm referrals work just as well with the
reverse-dns based canonical name as long as it is a valid principal.
The other reason (be resilient against wrong reverse-dns setups) could
still be a reason to use this patch, but now that I think of it it, it
probably doesn't buy you much as you need proper forward dns anyway so
better have a proper reverse dns too. Therefore I withdraw my patch.

Regards, Geert
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org