PA Data and KLApi's
Jeffrey Hutzelman
jhutz at cmu.edu
Fri Jan 23 12:29:56 EST 2004
On Friday, January 23, 2004 08:23:34 -0800 Mike Friedman
<mikef at ack.berkeley.edu> wrote:
> It worked fine (TGT issued on initial request) until a user with an old
> principal that had been created under V4, whose key is still V4 salted
> ('DES cbc mode with CRC-32, Version 4') reported that his authentication
> failed. The KDC log did, indeed, show 'preauth failed'.
>
> What I don't understand is why doing the preauth in response to 'NEEDS
> PREAUTH' works for this V4 key, but doing preauth on the initial AS
> request doesn't. I had to back out my change, because we still do have
> a bunch of old V4-created principals.
There are two different errors involved here. If you send a request
without preauth, and the KDC requires it, you get a "preauth required"
error. Along with the error you get various useful bits of information,
such as what preauth types are supported by the KDC, what enctype(s) the
KDC has keys for you for, and what the salt strings were. In the case of a
principal that was converted from V4 and has never had its password
changed, the salt string is '', which is not the same as the default.
If you send a request with preauth, and there is a problem (for example,
you encrypted your timestamp with the wrong key), you get a "preauth
failed" error.
So if you try to do optimistic preauth, you need to guess what key type and
salt string to use, and if you're wrong, you get "preauth failed." For
principals whose passwords have been changed since you upgraded to krb5,
the guess will be correct. For those which haven't, the guess will be
wrong.
-- Jeffrey T. Hutzelman (N3NHS) <jhutz+ at cmu.edu>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA
More information about the krbdev
mailing list