On Tue, 2008-06-03 at 10:58 -0400, James Carlson wrote: > Mark Phalan writes: > > > > On Tue, 2008-06-03 at 09:49 -0400, James Carlson wrote: > > > 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). > > I see. Perhaps a boot-time (or one-time on upgrade) warning if the > path is specified in kdc.conf? > > > 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. > > I guess I was thinking more about what happens when things are > restored from backup; the key will always be the one in the db, even > if a different one is (somehow) given elsewhere. Perhaps that just > doesn't happen in practice ...
The one in the Kerberos db is the one that matters as that's the one the KDC will use to generate service tickets with. Having the key in two different places (kadm5.keytab and the kerberos db) and out-of-sync will currently prevent kadmind from working properly. With this change the out-of-sync class of errors just goes away - the key material is in just one place: the Kerberos db. If the user restores a Kerberos db from backup but not kadm5.keytab, it will work (old behaviour: not work). If the user restores kadm5.keytab from backup but not the Kerberos db, it will work (old behaviour: not work). So I don't see any new issues when backups are involved. -M
