[31562] in Kerberos
Re: Zero-length entry in a keytab: why?!
daemon@ATHENA.MIT.EDU (kerberos@noopy.org)
Fri Oct 9 00:11:12 2009
MIME-Version: 1.0
In-Reply-To: <cba4e37e0909180417t308ff22dkbca6fb14576a54b4@mail.gmail.com>
Date: Thu, 8 Oct 2009 21:16:50 -0400
Message-ID: <cba4e37e0910081816w486a1d5as7a2886ef6848c217@mail.gmail.com>
From: kerberos@noopy.org
To: Ezra Peisach <epeisach@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Fri, Sep 18, 2009 at 7:17 AM, Nathan Patwardhan <noopy.org@gmail.com> wrote:
> On Thu, Sep 17, 2009 at 8:34 PM, Ezra Peisach <epeisach@mit.edu> wrote:
>
>> 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...
>
> Centrify.
I resolved this issue a couple of weeks ago. I cannot say 100% what
Centrify does behind the scenes to create a keytab but I *can* say
that their implementation spewed a bunch of NULL records from their
keytab when I bumped up the debugging in my code -- or at least their
NULL stuff that wasn't on spec with either MIT or Heimdal keytab
formats -- such that I had a problem parsing Centrify-created keytabs
reliably with my code.
I ended up skipping these NULL records and comparing 'klist -k -e -K
-t' of my generated keytab (based on parsing the Centrify keytab and
excluding about many lines of NULLs) versus the Centrify keytab and
everything matched up. I am convinced that there's just some
weirdness going on with Centrify keytab creation and I will file a bug
report with them, in particular since their keytab was 10k and my
rendition of the same was 2k.
--
K
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
