Changing password for a principal reverts master key used
Greg Hudson
ghudson at MIT.EDU
Thu Aug 1 11:56:02 EDT 2013
Okay, I see two bugs (or at least arguable bugs) here:
1. If the KDB was created prior to krb5 1.7, it will have no mkey
activation list in its K/M entry, and will not get one until "kdb5_util
use_mkey" is performed. In the absence of this list, the first master
key entry (the one with the highest kvno) is considered to be active,
and kdb5_util list_mkeys will list the current time as the active-on
time for all entries. "kdb5_util add_mkey" ought to create the list if
it does not exist.
2. kadmind caches the mkey activation list at startup and never
refreshes its cache, so kadmind must be restarted for use_mkey to take
effect. This was apparently considered during the master key migration
project, but apparently wasn't documented. We ought to either document
this constraint or remove it. Removing the constraint comes at the cost
of an extra DB lookup for each key change operation, which probably
isn't a big deal.
I will file bugs for these, and we will hopefully get around to fixing
them soon, along with the update_princ_encryption bug.
More information about the Kerberos
mailing list