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