[16322] in Kerberos_V5_Development
Re: Project Review: kinit -C
daemon@ATHENA.MIT.EDU (Nicolas Williams)
Thu Sep 16 17:46:28 2010
Date: Thu, 16 Sep 2010 16:44:58 -0500
From: Nicolas Williams <Nicolas.Williams@oracle.com>
To: Sam Hartman <hartmans@mit.edu>
Message-ID: <20100916214458.GM3982@oracle.com>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <tslzkvhfmvg.fsf@live.mit.edu>
Cc: Ken Raeburn <raeburn@mit.edu>, "krbdev@mit.edu Dev List" <krbdev@mit.edu>,
Tom Yu <tlyu@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
On Thu, Sep 16, 2010 at 04:34:59PM -0400, Sam Hartman wrote:
> >> That would just leave the question of whether pluggable keytab
> >> types are a good idea. :-)
>
> Tom> I think it's a great idea. I'm not sure that we have time to
> Tom> implement it for the 1.9 release.
>
> As do I.
> Especially given that kinit -C ended up being taken and the syntax I
> ended up with was
> kinit -k -t KDB:
> Ken's solution works well.
+1
> I actually thought about a preauth plugin or a locate plugin that
> registered the kdb keytab in its initialization function combined with a
> change to the KDB keytab to take the realm of the KDB as its argument.
> I decided that having preauth plugins or locate plugins as a hook for a
> keytab registration was architecturally impure.
You don't strictly need that realm name argument, though I welcome
it.
IMO there should be a single KDB per-KDC host because: a) one should use
VMs to run distinct realms' KDCs on a single system, b) the KDB
technically can (and _does_, for cross-realm principals anyways) store
entries for principals in more than one realm. So I'd not be upset if
you didn't add that argument.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
