[32791] in Kerberos
Re: What are the issues with dns_lookup_realm ?
daemon@ATHENA.MIT.EDU (Brian Candler)
Mon Oct 11 10:23:00 2010
Date: Mon, 11 Oct 2010 15:22:52 +0100
From: Brian Candler <B.Candler@pobox.com>
To: "Christopher D. Clausen" <cclausen@acm.org>
Message-ID: <20101011142252.GA5597@talktalkplc.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <7D7825AE41E846799071B10540E9E54A@CDCHOME>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Mon, Oct 11, 2010 at 08:54:50AM -0500, Christopher D. Clausen wrote:
> >What was even more odd, if I did a 'su' to the apache user, I was able to
> >'kinit' using one of the usernames/passwords which apache was rejecting as
> >Basic Auth credentials. Surely mod_auth_kerb should be doing the same??
>
> There is more to it than just a kinit, unless you have KrbVerifyKDC
> off which you shouldn't b/c it can be a security problem.
> Mod_auth_kerb is just blindly trusting that ANY successful Kerberos
> reply comes from your KDC with this turned off. When it is on, it
> uses its keytab to verify that the KDC that responded is legit and
> not one an attacher setup.
That makes a lot of sense.
> The requested service principal name would likely be logged on the
> KDC when apache tries to authenticate users and produces this
> message.
Good point. Unfortunately, in this particular scenario, the KDC is Windows
AD (which I have little visibility of, nor desire to learn :-) But in any
case, I did capture the packets going to/from the KDC, and saw the username
and expected (user's) realm in them.
But following your explanation above, I guess something like this is
happening:
- 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
That would explain the error message seen. I was expecting default_realm to
be used, but as Greg already told me at
http://mailman.mit.edu/pipermail/kerberos/2010-October/016586.html
''The misunderstanding here is that "the default realm" is not the default
for host-to-realm mappings. It's the default for parsing principal
names which don't contain realms--for example, if you "kinit bcandler"
instead of "kinit bcandler at EXAMPLE.COM".''
Maybe it would be cleaner if the client code failed immediately when asked
to map a host to a realm but was unable to? An error like "unable to find
realm for host 192.0.2.1 (rails.api.example.com)" would have been easier for
me to interpret.
Regards,
Brian.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
