Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Documenting the kerberos KDC log file format

471 views
Skip to first unread message

Todd Grayson

unread,
Jan 31, 2017, 1:02:11 AM1/31/17
to kerb...@mit.edu
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?

I'm guessing that having it in syslog format would be better... but thats
out of my control...

--
Todd Grayson
Business Operations Manager
Customer Operations Engineering
Security SME

Benjamin Kaduk

unread,
Jan 31, 2017, 10:13:27 AM1/31/17
to Todd Grayson, kerb...@mit.edu
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

unread,
Jan 31, 2017, 10:14:45 AM1/31/17
to Benjamin Kaduk, kerb...@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

Benjamin Kaduk

unread,
Jan 31, 2017, 7:15:05 PM1/31/17
to Todd Grayson, kerb...@mit.edu
On Tue, Jan 31, 2017 at 12:44:20AM -0600, Benjamin Kaduk 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.

I guess I should also note that if you are starting from a clean-slate,
there is a more programmatic interface available to this sort of KDC log
data via the experimental audit plugin framework
(http://k5wiki.kerberos.org/wiki/Projects/Audit) where you could write
code to have a loadable module that can log in whatever format you want.
The project is considered "experimental" in that the interface is not guaranteed
to remain stable across releases. But maybe it is useful for your situation.

-Ben
0 new messages