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

[Dominic Hargreaves]

[migrating this thread to my work email]

On Sun, Mar 14, 2010 at 02:15:51PM -0700, Russ Allbery wrote:
> 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).

In fact I think we *are* using Heimdal on the server side in order
that the refreshandPersist syncrepl connections don't break after
the original credentials expire...

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

Thank you for the excellent explanation. I would be very interested
in details of the Cyrus patch you have. Has it been offered upstream
at all?

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

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

So, just to clarify, the original Net::LDAP (without my bad patch)
would have worked with your DNS round-robin based service?

Thanks,
Dominic.

-- 
Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20100318/19aa21a8/attachment.pgp>