Preauth and ticket forwarding

Chaskiel M Grundman cg2v at andrew.cmu.edu
Tue Dec 7 17:57:47 EST 2004



--On Tuesday, December 07, 2004 20:18:28 +0000 Rachel Elizabeth Dillon
<red at MIT.EDU> wrote:

> 
> 1. What does preauth _actually_ do? From some reading, I believed it to
>    be based on clock skew, and fixed the clock skew between the VPN box
>    and the Kerberos server, but preauth still fails. 
preauthentication mechanisms are used to "prove" to the kdc that the client
requesting the ticket really is the user. The only widely implemented
preauth mechanism in use at this time is PA-ENC-TIMESTAMP which is
basically a timestamp encrypted with the long-term key of the user. If
there is excessive clockskew then this preauth mechanism won't work.

Based on the log data you showed later, it appears that the cisco software
does not support preauthentication or (less likely) only supports
mechanisms not supported by your kdc.

you ought to be able to tell if the client is sending a second request by
using tcpdump or ethereal to capture packets from the network while the
client is attempting to authenticate. (tcpdump does not have much of a krb5
packet dissector, but you can capture packets on the kdc with tcpdump -w,
and copy the file to another system to run ethereal)

you should see 2 AS-REQ's. One will fail, with
KRB5KDC_ERR_PREAUTH_REQUIRED, and the second will succeed, returning an
AS-REP packet. If you do not see a second request from the client, it means
that it doesn't support preauth. (or the right preauth)

> 
> 2. Assuming I have no choice but to turn off preauth for the Cisco box,
>    is there any way to make SSH ticket forwarding work with preauth
>    turned off? It works just fine as my system stands with preauth turned
>    on, but when preauth goes off, ticket forwarding stops working. This
>    makes sense as a security feature and I realize I am shooting myself
>    in the foot, but I am being ordered to shoot myself in the foot, and 
>    I am trying to minimize immediate bleeding. :)

The two features are not related. It's possible that the operation of
disabling preauth somehow is dissociating the principals from the policy
object they were using before. make sure that the user's principal (or
relevant policy) and the krbtgt principal (or relevant policy) does not
have DISALLOW_FORWARDABLE set on it.




More information about the Kerberos mailing list