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). > 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 ([email protected]) <http://www.eyrie.org/~eagle/> -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
