clock skew and preauth

[Chris Hecker]

> I think the error message you're seeing is from the encrypted 
> timestamp preauth, not the FAST encrypted challenge preauth. Are you 
> doing anything that would trigger FAST?

I don't know enough to answer that question.  When I break in
process_as_req, the request->padata is 149 the first time through, and
then 2, 133, and 149 the second time through.  138
(KRB5_PADATA_ENCRYPTED_CHALLENGE) doesn't show up there, yet gdb says
the .so is loaded, and I can set breakpoints in it (that don't get hit).
 There's no error in the krb5kdc.log for it (there is a log entry for
pkinit preauth, for example, which I don't use and haven't set up).

Does the fact that it doesn't show up in request->padata mean I'm not
setting it right on the client side or something?

Chris


On 2012/03/20 16:19, Tom Yu wrote:
> Chris Hecker <checker at d6.com> writes:
> 
>> Also, the encrypted_challenge_main.c file does check this:
>>
>> if (labs(now-ts->patimestamp) < context->clockskew) {
>>
>> and gives the KRB5KRB_AP_ERR_SKEW error, which is the same check the
>> timestamp preauth does, so I don't see how it could work.  But, I'm
>> having trouble getting gdb to break there, so I'm not sure it's getting
>> called.
> 
> I think the error message you're seeing is from the encrypted
> timestamp preauth, not the FAST encrypted challenge preauth.  Are you
> doing anything that would trigger FAST?
>