[37844] in Kerberos
Re: Documenting the kerberos KDC log file format
daemon@ATHENA.MIT.EDU (Todd Grayson)
Tue Jan 31 10:14:48 2017
MIME-Version: 1.0
In-Reply-To: <20170131064420.GC8460@kduck.kaduk.org>
From: Todd Grayson <tgrayson@cloudera.com>
Date: Tue, 31 Jan 2017 00:00:22 -0700
Message-ID: <CALNT6MVx6hrtnJ-uWr+CqHGLHZB=yThpKU8BerHk+FfWK9yX_w@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: "kerberos@MIT.EDU" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Yeah I'm looking for the REQ layout, the other message types are variable
to the point where they are being filtered out (altho I pause dropping FD
closing down messages...)
so something like the following, note authtime field is a mystery (or
something is really really broken in the logs I'm looking at) its not
clear if ISSUE is variable, I see only the same output but that might not
cover error conditions...
[date] [time] [kdc fqdn?] [process-name][[pid]]([level]): [REQ-TYPE of
AS_REQ or TGS_REQ] ([enc-types output]}) [REQ-IP] [??ISSUE:??] authtime
[auth time in? epoc time? what is this], etypes [selected enctypes across
rep,tkt and ses]}, [requesting_principal] for [requested_principal]
If anything in the future keeping the default log format but allowing a log
file format expression string for defining custom output format for
request/response entries would be interesting
On Mon, Jan 30, 2017 at 11:44 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> On Mon, Jan 30, 2017 at 11:01:46PM -0700, Todd Grayson wrote:
> > Has anyone seen a good writeup of the krb5kdc.log file output format?
> For
> > the types of log file output statements that it writes out. So for
> example
> > the AS_REQ and TGS_REQ and follow up "closing down" lines representing a
> > full connection span.
> >
> > More specifically does anyone have any content or pointers to
> constructing
> > good parsers for turning this log data into record data? Parser tools
> for
> > the default MIT KDC log format?
>
> Unfortunately, the idea of a unified format was not in mind when things
> were originally written, so a programmatic parse will be somewhat
> difficult.
> We've tried to be more careful with more recent additions, but feel rather
> constrained to not change the historical behavior and break existing
> log-parsing scripts.
>
> Maybe someone else on the list has some prior art that you could start
> from, though.
>
> -Ben
>
--
Todd Grayson
Business Operations Manager
Customer Operations Engineering
Security SME
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
