Return-Path: <tlyu@MIT.EDU>
Received: from mailhub-auth-1.mit.edu (MAILHUB-AUTH-1.MIT.EDU [18.9.21.35]) by krbdev.mit.edu (Postfix) with ESMTPS id 31FA75BC34 for <rt@krbdev.mit.edu>; Wed, 14 May 2014 15:21:23 -0400 (EDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id s4EJLMsj000306 for <rt@krbdev.mit.edu>; Wed, 14 May 2014 15:21:23 -0400
Received: from localhost (sarnath.mit.edu [18.18.1.190]) (authenticated bits=0) (User authenticated as tlyu@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id s4EJLLsa014482 for <rt@krbdev.mit.edu>; Wed, 14 May 2014 15:21:22 -0400
From: Tom Yu <tlyu@MIT.EDU>
To: rt@krbdev.mit.edu
Subject: Re: [krbdev.mit.edu #7910] krb5-1.12 logging incomplete (PROCESS_TGS - Ticket expired)
References: <rt-7910-40646.5.78862600036935@krbdev.mit.edu>
Date: Wed, 14 May 2014 15:21:21 -0400
In-Reply-To: <rt-7910-40646.5.78862600036935@krbdev.mit.edu> (Richard Basch via's message of "Tue, 13 May 2014 22:21:47 -0400 (EDT)")
Message-ID: <ldvha4sjhe6.fsf@sarnath.mit.edu>
Lines: 19
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
RT-Send-Cc: 
X-RT-Original-Encoding: us-ascii
Content-Length: 979

"Richard Basch via RT" <rt-comment@krbdev.mit.edu> writes:

> When a TGT has expired but is presented to the KDC, the KDC will log
> <unknown client> for server_principal@REALM, Ticket expired.
>
> Though patches have already been adopted to correct the service principal
> logging (which was faulty in 1.11 & 1.12), the client principal is not
> properly decoded/displayed, especially in the "expired ticket" case. This
> can make diagnostics a little more challenging in some cases.

I agree that omitting the client name from that error can make
diagnostics challenging.  I think we've known about this issue for quite
some time, but haven't figured out a good way to fix it yet.

I would not expect fixing this to be easy.  As I recall, there would
need to be changes to the error paths in rd_req_decoded_opt() to
preserve some of the decrypted and decoded ticket contents, and we would
consequently have to work harder to correctly manage the associated
memory allocations.