[33415] in Kerberos
Re: Changing the master key
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sun May 22 11:42:21 2011
From: Greg Hudson <ghudson@mit.edu>
To: John Devitofranceschi <jdvf@optonline.net>
In-Reply-To: <129310F8-D428-4289-9FE8-89EB6800D0A4@optonline.net>
Date: Sun, 22 May 2011 11:42:10 -0400
Message-ID: <1306078930.2034.292.camel@t410>
Mime-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
On Sun, 2011-05-22 at 09:19 -0400, John Devitofranceschi wrote:
> From your description of the issue, it seems that if the old mkey is
> purged from the master db after conversion and the slaves are then
> re-initialized from scratch, this problem can be avoided.
Simply purging the old mkey should be adequate to work around the bug, I
think. An entry with no master key entry is treated (in 1.8.2, anyway)
as having the minimum master key version, so the buggy principal entries
should magically snap from 1 to 2 once the old mkey version is purged.
At any time, rebuilding the slaves with a full kprop should populate the
master key version of all current principal entries on the slaves, but
new entries will continue to be missing the master key version field
until the bug is fixed in the slaves' code base (libkdb5 as used by
kpropd).
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
