[21071] in Athena Bugs
Re: Login puzzle
daemon@ATHENA.MIT.EDU (Kev)
Thu Nov 14 13:50:12 2002
Message-Id: <200211141849.NAA30996@zygorthian-space-raiders.mit.edu>
To: Tom Cavin <cavin@mit.edu>
cc: SIPB Linux Help <linux-help@mit.edu>, Athena Bugs list <bugs@mit.edu>
In-Reply-To: Your message of "Thu, 14 Nov 2002 13:38:11 EST."
<15827.60819.86320.334283@lap1-wccf.mit.edu>
Date: Thu, 14 Nov 2002 13:49:28 -0500
From: Kev <klmitch@MIT.EDU>
> My Questions:
>
> 1. What tools can I use to get the srvtab/keytab versions so I can
> compare local files with the corresponding versions on the KDC?
Take a look at the commands available in ktutil. There should be flags
for klist that list the key version numbers for credentials in your
cache, so that should help you take a look at the version numbers and
compare them.
> 2. What happens in normal login process for a normal user that isn't
> happening here?
If a keytab/srvtab is present, the normal login process will request a
credential on the behalf of the logging-in user and see if it can
authenticate to itself--this provides some protection against someone
gaining access by providing a fake KDC.
> 3. What does the error message from krb_rd_req mean? And more
> generally, where can I find documentation on these errors?
The check I mentioned in part 2 builds an authenticator with the
user's credential and then tries to decrypt it with the key in the
system's keytab/srvtab, which fails due to version skew. I do not
know of good documentation for the kerberos error messages other
than the source or having some idea of what's going on.
> 4. Is there a way to get the system to tell me what's different or
> missing?
Not really. Kerberos works on the basic assumption that the key in
the keytab and the key on the KDC are the same, and there's no direct
way to verify that except to try to get a credential for the
principle(s) in the keytab, which is not a common (or recommended!)
operation. I'm not even sure the KVNO is passed in the
authenticator--if it were, Kerberos could give you a better error
message.
Error reporting is one of the things that Kerberos really sucks in.
--
Kevin L. Mitchell <klmitch@mit.edu>
