[migrating this thread to my work email] On Sun, Mar 14, 2010 at 02:15:51PM -0700, Russ Allbery wrote: > Dominic Hargreaves <[email protected]> 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
signature.asc
Description: Digital signature
