[33412] in Kerberos
Changing the master key
daemon@ATHENA.MIT.EDU (John Devitofranceschi)
Sat May 21 10:28:28 2011
Date: Sat, 21 May 2011 10:28:21 -0400
From: John Devitofranceschi <jdvf@optonline.net>
To: kerberos@mit.edu
Message-id: <837B3143-0986-40B2-A73D-9BB4BD81806B@optonline.net>
MIME-version: 1.0
Content-Type: multipart/mixed; boundary="===============1419245272=="
Errors-To: kerberos-bounces@mit.edu
--===============1419245272==
Content-type: multipart/signed; boundary=Apple-Mail-1--884096611;
protocol="application/pkcs7-signature"; micalg=sha1
--Apple-Mail-1--884096611
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
=09
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.
The master kdc is behaving as expected, and all new principals report =
using the new mkey vno.
On the master and all slave kdc's, "kdb5_util -list_mkeys" shows that =
the new mkey vno is active master key.=20
I have no idea what steps were used to change the master key (not my =
infra) and I'm wondering if this situation can be fixed.
I've searched for a "Dummies Guide to Changing your MKey" but I've only =
found bits and pieces here and there with no real indication of how =
slaves enter into the picture. Should they be recreated from scratch =
once the master is changed?
Any pointers or help appreciated!
jd
--Apple-Mail-1--884096611--
--===============1419245272==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
--===============1419245272==--
