> I assume you mean krb5_rd_req_decoded would set the ticket output
> value in cases where it decrypts and decodes successfully but
> doesn't validate?
Yeah, and the caller would be responsible for calling
krb5_free_enc_tkt_part if the ticket is non-null instead of it being
called in cleanup: a
On Thu, 2011-07-28 at 19:19 -0400, Chris Hecker wrote:
> 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
I assume you mean krb5_rd_req_de
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 o
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, for , Ticket expired
This is slightly less than useful for finding which client is submitting
expired TGTs.
rd_req_deco
