KDC TGS_REQ ticket expired log message has no client or server info

Chris Hecker checker at d6.com
Thu Jul 28 19:19:37 EDT 2011


Hmm, digging deeper, the krb5_rd_req_decoded(_anyflag) functions are in 
k5-int.h, and are only called from a couple places throughout all the 
code.  I could easily have them leave client even on failure, if I 
documented that the caller needed to free it if it's non-null, and fixed 
the couple of call sites.  Since it's internal, I assume other people 
outside krb5 aren't calling it (or deserve what they get :), and so 
would a change like this be acceptible?  It would change the error below to:

> Jul 28 04:28:17 example.com krb5kdc[14031](info): TGS_REQ (1 etypes
> {18}) 1.1.1.1: PROCESS_TGS: authtime 0, a at FOO.COM for
> <unknown server>, Ticket expired

for no performance penalty at all, which seems like a win for debugging 
and security?

Chris


On 2011/07/28 02:45, Chris Hecker wrote:
>
> A typical failed TGS_REQ for an expired ticket looks like this:
>
> Jul 28 04:28:17 example.com krb5kdc[14031](info): TGS_REQ (1 etypes
> {18}) 1.1.1.1: PROCESS_TGS: authtime 0, <unknown client> for <unknown
> server>, Ticket expired
>
> This is slightly less than useful for finding which client is submitting
> expired TGTs.
>
> rd_req_decoded_opt computes the enc_part2->client, but then immediately
> toasts it on error out.
>
> It's pretty deep down so I guess it'd be a pain to fix, but it's a
> shame, since the information for a good error is computed, it's just
> thrown away too early.
>
> Thoughts?
>
> Chris
>
>



More information about the Kerberos mailing list