Bug#573596: libnet-ldap-perl: Net::LDAP passes the wrong remote server identity to SASL

[Russ Allbery]

Dominic Hargreaves <dom at earth.li> writes:

> Ugh. That's my patch. I can only assume that the SASL GSSAPI library I
> was using (MIT I think) does the reverse lookup for itself if it spots
> what looks like an IP address (but I won't have time this weekend to dig
> into that), because it certainly "works" for us.

Ah, yes, that may well be the case.  I ran into this with a Heimdal GSSAPI
library since that's what we use for OpenLDAP (Heimdal is considerably
faster than MIT in OpenLDAP if you're doing lots of authentications).

> I found that various other callers (possibly including the OpenLDAP
> tools) did do host canonicalisation, so we had to change something to
> make things work.

I suspect, although I may be wrong, that you ran into a long-standing bug
in Cyrus SASL.

Background: the client and the server to some extent have to agree in
advance on what service principal is going to be used by the client to
authenticate to the server, since the client just tries something and the
authentication fails if that doesn't work.  Historically, the server also
picks something (usually a principal based on the canonical local
hostname), and unless both sides pick the same thing, the authentication
fails.

However, with any current GSSAPI library, this is not necessary on the
server side.  One can, instead, call the server end of the GSSAPI
connection setup and pass in a NULL name.  If one does this, then the
server will look at the service principal used by the client and attempt
to locate a matching key in the local keytab, thus supporting
authentication with any service principal that is listed in that keytab.
This lets you create keytabs that contain both, say, ldap/example.com and
ldap/ldap1.example.com and either will then work for authentication.

Unfortunately, Cyrus SASL doesn't do this.  It still builds a server-side
principal name and then accepts only that principal name.  We use a
one-line patch to Cyrus SASL to disable that behavior.  I suspect that's
what you ran into, since the Cyrus SASL default server principal is based
on the canonical local hostname.

> My understanding was that although flawed, host canonicalisation was the
> standard way of doing things in Kerberos land.

This has historically been the case, but there's increasing feeling that
it was a bad default.  For the most part, the default hasn't changed since
it would break too much software, but there are now flags that let you
disable it in most Kerberos implementations.  The model that people would
really like to use going forward is more like ssh's model, wherein
whatever you give on the command line is canonical, since that provides
more protection against DNS spoofing.

> In general I found it almost impossible to debug these sorts of
> connection problems which probably explains why the patch is in the
> semi-working state that it's in now - I don't know if I'm missing a
> trick but even with turning on all the debugging options I could find
> you can never get to the root cause of the authentication failure.

Yeah, GSSAPI authentication failures are difficult.  In general, the rule
of thumb is that the only details that are actually helpful are on the
server, and to get slapd to spit them out you usually have to start it
with debugging (-d 1).

> I'll use the sheer frustration that resulted as an excuse for the
> nonsensical patch which happened to fix it for us ;)

It's probably not non-sensical at all for MIT, just for Heimdal.  :)  I
should have thought of that.

>> If the user really wants GSSAPI to canonicalize the hostname, there's
>> generally a way to configure the underlying Kerberos library to do that
>> in krb5.conf.

> I'll look at that approach too in case it's any good for us.

Yeah, I'm not sure why this wouldn't have canonicalized the GSSAPI name
used on the client.  It may be that I'm wrong and there isn't actually a
way to tell the client to do this.

We normally only ran into trouble once we put LDAP servers behind a
hardware load balancer so that forward and reverse DNS of the IP address
still didn't resolve to the canonical hostname.  When we were using DNS
load balancing, the libraries seem to have done the right thing.  I'm not
quite sure off-hand what could have been different in your environment
(although I certainly believe what you saw; this area of authentication is
notoriously fragile).

-- 
Russ Allbery (rra at debian.org)               <http://www.eyrie.org/~eagle/>