On Mon, Oct 11, 2010 at 12:54:57PM -0400, Greg Hudson wrote: > On Mon, 2010-10-11 at 10:22 -0400, Brian Candler wrote: > > - mod_auth_kerb tries to find realm for rails.api.example.com > > (the virtual server hostname), via DNS lookups > > - mod_auth_kerb fails to find one > > - mod_auth_kerb looks for something duff like "HTTP/rails.api.example.com@" > > in its keytab, and fails > > I doubt it's actually failing. It's probably falling back to > API.EXAMPLE.COM as the best available heuristic; that happens to be the > wrong answer.
Is that the "domain heuristic"? This machine has (RedHat's version of) Kerberos 1.3.4, and I thought you said that capability was only introduced recently. In this case it would also give an invalid choice, because if it then goes ahead to try to find a KDC for API.EXAMPLE.COM, it won't find one - neither in DNS nor in [realms]. Which I guess is what you meant by this: > The code could, I suppose, try to determine whether API.EXAMPLE.COM is > actually a Kerberos realm, and then fall back to the default realm. > That has its own pitfalls, though; if API.EXAMPLE.COM ever became a > realm (through SRV records, say), you'd get an unexpected behavior > change. Yes, I agree it shouldn't fall back to the default realm. But it could fail the hostname->realm lookup. > In any event, I've committed a change for 1.9 which would make the error > message from the keytab lookup more informative: > > No key table entry found for HTTP/rails.api.example....@api.example.com For this case that gives a much clearer message, thank you. Regards, Brian. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos