On Thu, 23 Jan 2014 16:36:18 +0000 p...@afs.list.sabi.co.uk (Peter Grandi) wrote:
> The issue here is that at least in MIT kerberos 1.8 and 1.10 which I > tested this on this results in the loss of the existing single-DES key > from the KDB, That is intentional and expected. > which probably results in existing single-DES tokens and client to > stop working as the key in the 'KeyFile' is no longer matched by one > in the KDB: It does not prevent any already-issued tokens from working, but it does make authentication not work correctly for any new tokens until you distribute the new rxkad.keytab file. That is expected, and noted in the "Basic procedure". Using one of the other rekeying procedures allows you to reduce or eliminate the amount of time where authentication is broken. > To avoid this one has to use 'kadmin.local' to be able to use 'cpw > -keepold' and 'ktadd -norandkey', as advised in the MIT kerberos > "Retiring DES" HOWTO: > > > http://web.mit.edu/kerberos/krb5-current/doc/admin/advanced/retiring-des.html That part of the document is talking about the krbtgt/ service principal, which is a special case. If you retain the old DES key while rekeying the afs/ service principal, it doesn't really... do anything. At least, I can't think of any differences that actually results in. The KDC should only issue tickets encrypted with the new kvno, and after tickets are issued, the KDC will never look at the ticket again. This is different for the krbtgt/ service principal, since for that, the KDC _does_ need to look at the service ticket again after it's issued (for issuing other tickets). If you're looking to avoid the "authentication breaks" period while still doing something like the "Basic procedure", you would need to be able to 'cpw -keepold', but disable the new non-DES keys. Then you could extract the keys into a keytab, distribute them, and then enable the new non-DES keys and disable or delete the old DES keys. I'm not aware of a way to do with that an MIT KDC; if that's possible, it would be rather new, I think. The "ktutil procedure" in the rekeying document does basically that, though; it's just that the new non-DES keys are not stored on the KDC until the final step when you enable them. > Looks to me There is a bug in the MIT Kerberos 'ktadd -norandkey'. Yeah, it does looks like it gives you the wrong kvno when you have multiple kvnos for the princ. That shouldn't be impacting this procedure, though. -- Andrew Deason adea...@sinenomine.net _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info