Zero-length entry in a keytab: why?!

Nathan Patwardhan at
Fri Sep 18 07:17:32 EDT 2009

On Thu, Sep 17, 2009 at 8:34 PM, Ezra Peisach <epeisach at> wrote:
> ---------- Forwarded message ----------
> From: Ezra Peisach <epeisach at>
> To: kerberos at
> Date: Thu, 17 Sep 2009 20:34:13 -0400
> Subject: Re: Zero-length entry in a keytab: why?!
> Howdy,
> a) You describe a variable bytesRemain - neither MIT nor Heimdal use such a
> variable - so this might be your code.

Yes, these variables are in my code.  Thought I'd mentioned that.
Sorry if I wasn't clear.  :-(

> b) You mention a vendor app writing such a keytab with holes - care to
> mention who? I suspect they might have extended their definition of a keytab
> in a non-standard way... You can ask the vendor...


> d) Heimdal has another extension -after the version number, if there are 4
> bytes - a flag for the entry can be stored.... Not sure off hand what for...

Yeah, I think this describes what I'm seeing -- even if not specific to Heimdal.

> e) You mention that klist and ktutil can read the keytab - which vendor
> program are you using? I suspect not MIT.

If I'm seeing things correctly, Centrify ships with its own version of
the MIT binaries (klist, kinit, etc).  But your assertion made me
think about Heimdal a lot.  I am going to read their keytab code and
see if I can understand where things might be amiss here.  Certainly
there are many, many cases in my existing keytab where there are *NO*
extra bytes after the keyblock, and even when i look at the bytes
after the keyblock I can't figure how these would represent a vno for
that matter.

Also, looking further at the keytab in a binary editor I see a ton of
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ffffff at the end of the file --
without any other keytab entries following that data.  This just
doesn't seem like the case in any other keytabs I've looked at.


More information about the Kerberos mailing list