Changing the master key

[John Devitofranceschi]

Thanks a lot for this. We'll try out the patch ASAP.

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.

Is that accurate?

jd


On May 21, 2011, at 10:18 PM, Greg Hudson wrote:

> On Sat, 2011-05-21 at 10:28 -0400, John Devitofranceschi wrote:
>> We've run into a situation with MIT Kerberos 1.8.2 where the master
>> key has been changed and yet the slave kdc's are still reporting that
>> the original master key is being used on new principals.
>> 
>> Slave kdc updates are happening via iprop.
> 
> I was able to reproduce and debug this problem.  The per-principal
> master key version is stored in a tagged-data entry in the principal
> entry.  There is a long-standing bug in the way iprop receives
> tagged-data updates, causing it to ignore all but the first entry.  The
> master key version happens to appear second in the list when a principal
> is added, so it gets lost.
> 
> I would guess that under 1.8.x this bug causes new principals to be
> inaccessible from the slave KDC, which is pretty bad.  In 1.9.x the bug
> would be fairly harmless, as the KDC has stopped caring about the
> principal's master key version (it just tries all master keys).  Some
> admin programs still care about the per-principal master key version,
> but you wouldn't typically run those on slaves.
> 
> I've tested and committed a fix to the trunk code.  There has been a
> little bit of code drift between 1.8 and trunk, so I'm attaching a patch
> against 1.8.x.  I haven't tested the 1.8 change except to make sure it
> compiles, but I'm confident it will behave identically to the trunk
> change.
> <patch.txt>