On Tue, 2008-06-03 at 09:49 -0400, James Carlson wrote: > Mark Phalan writes: > > > > On Tue, 2008-06-03 at 09:28 -0400, James Carlson wrote: > > > Wyllys Ingersoll writes: > > > > With the latest resync of Kerberos with MIT Kerberos 1.6.3 (in > > > > progress) kadmind(1M) reads the keys it needs directly from the > > > > Kerberos database. Prior to this a keytab file had to be populated > > > > with the keys kadmind required. By default this file was located at > > > > /etc/krb5/kadm5.keytab. > > > > > > Is there anything that the administrator needs to do to make the new > > > scheme work? Do the existing keys need to be transferred out of that > > > file somehow? > > > > The administrator doesn't need to do anything. The keytab will just no > > longer be used - instead the keys will be directly read from the > > kerberos db. > > The administrator may want to delete that file (as its no longer used) > > but that isn't necessary. > > OK. Perhaps the file should be deleted on system upgrade, so that the > user doesn't try to do something silly, like modify the file and > expect it to do something.
That might be a good idea (although locating the file - parsing kdc.conf - might be tricky). As kadm5.keytab is generally managed with the "kadmin/kadmin.local" commands there is little scope for the user to become confused - the kerberos db is always updated when using those commands to modify keytabs. The only scenario I can think of where the user may not get what he expects is when he purposly tries to make kadmind fail by deleting or corrupting kadm5.keytab. In this scenario kadmind will still continue to work when the user may expect it to fail. -Mark
