[33724] in Kerberos
Re: KDC TGS_REQ ticket expired log message has no client or server
daemon@ATHENA.MIT.EDU (Chris Hecker)
Mon Aug 8 03:42:34 2011
Message-ID: <4E3F9365.1000000@d6.com>
Date: Mon, 08 Aug 2011 00:42:29 -0700
From: Chris Hecker <checker@d6.com>
MIME-Version: 1.0
To: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <1312782895.2242.28.camel@ray>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
> 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: at the bottom of rd_req_decoded_opt. It's only
called in a couple places, and the more public and common krb5_rd_req
could just delete it on failure to stay compatible.
> I think it would be possible to log the server name as well, since
> that's just sitting in the request structure. I know that's less
> interesting to you.
That'd be great, the more detailed logging the better, especially if
it's free!
Chris
On 2011/08/07 22:54, Greg Hudson wrote:
> 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_decoded would set the ticket output value
> in cases where it decrypts and decodes successfully but doesn't
> validate? I think that would be acceptable, and there even seems to be
> KDC code to handle this case.
>
> I think it would be possible to log the server name as well, since
> that's just sitting in the request structure. I know that's less
> interesting to you.
>
>
>
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
