Changing password for a principal reverts master key used
David Shrimpton
d.shrimpton at its.uq.edu.au
Thu Aug 1 02:09:14 EDT 2013
On Thu, 1 Aug 2013, Greg Hudson wrote:
> On 07/31/2013 01:11 AM, David Shrimpton wrote:
> > KNVO: 2, Enctype: aes256-cts-hmac-sha1-96, Active on: Wed Jul 31 14:45:32 EST 2013 *
> > KNVO: 1, Enctype: des-cbc-crc, Active on: Wed Jul 31 14:45:32 EST 2013
>
> This is a weird state. Both master keys have the same "Active on" time,
> and they are both in the future (as of when you sent the message). I
> can't easily get into that state in a test environment:
The EST in this case is Australian EST and is GMT+10.
The "Active on time" displayed by list_mkeys was always the
time that the list_mkeys was run and was always the same for each
MKey so was 'now' rather than in the future.
Incidently master_key_type = des-cbc-crc in kdc.conf, but if some
principals have MKey des and some aes this setting is not right
for some. It also won't be right after the time
that the aes master key becomes active.
The cpw reverts MKey problem dissappeared overnight and I have been
unable to reproduce yet.
The list_mkeys showing 2 keys with the current time problem persisted
but was fixable by doing a 'use_mkey 2 time' where time was in the past.
'time' in the future would cause "Invalid argument there must be one master key currently active" error.
> So, I'm curious how you got into that state. Perhaps there is a bug
> involved with that sequence of events.
I'll try to reproduce the problem again. I guess if all principals
are converted using update_princ_encryption and the old MKey is purged
before any users can attempt a password change then the problem goes
away.
>
> There is a known bug that update_princ_encryption always chooses the
> most recent master key, rather than the one which should be currently
> active:
This does seem to be the case. Running update_princ_encryption doesn't
appear to change MKey to a lower numbered MKey even if that MKey
has been made the active one. Rolling back a MKEy change would appear
to be problematic.
David Shrimpton
More information about the Kerberos
mailing list