"Key table entry not found while getting initial credentials" + KRB5KDC_ERR_PREAUTH_REQUIRED

[Henry B. Hotz]

I agree that's the desired behavior:  an AS_REQ based on a keytab  
should use the intersection of the enctypes supported in the library  
and the enctypes in the keytab for the principal in question.

I've had to deploy something like that, but my patch isn't general  
enough to be useful to this audience.

On May 14, 2008, at 9:12 AM, krbdev-request at mit.edu wrote:

> Date: Wed, 14 May 2008 11:04:10 -0400
> From: Ken Raeburn <raeburn at MIT.EDU>
> Subject: Re: "Key table entry not found while getting initial
> 	credentials" +	KRB5KDC_ERR_PREAUTH_REQUIRED
> To: Igor Mammedov <niallain at gmail.com>
> Cc: krbdev at mit.edu
> Message-ID: <D8EE9914-E6CE-44D6-B880-EEB90FA14AE4 at mit.edu>
> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>
> Another workaround would be to put keys of all supported types into
> the keytab, not just one.  It's not a 100% solution, because if you
> upgrade the implementation and it adds new encryption types that the
> KDC also knows about, that won't automagically update the keytab
> file.  Or, save away the password itself and use it when getting new
> credentials; also not a great idea, depending on the use case and
> threat model.
>
> For a server principal, it's expected that the KDC knows the set of
> encryption types available.  But for password-based user keys saved
> away, yes, perhaps we should be using the actual enctypes stored....
>
> Ken

------------------------------------------------------
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu