Kerberos Delegation Account Password Change

Hi Mike,

the key material in the keytab is derived from the Kerberos shared secret (the account passowrd). So whenever you change the password of your service account, the keytab must be updated/renewed. There is no way around...

Keep in mind that a kerberos client may cache kerberos tickets for the duration of the maximum kerberos ticket lifetime. In this case the client will not ask the KDC to get a fresh kerberos ticket. Instead, it would just use the cached kerberos ticket matching the outdated keytab file. If the kerberos ticket expires and the client asks your KDC for a new service ticket, it will then break...

Note: Changing the passwords of low priviledge service accounts once a year is in my opinion somewhat paranoid. If you use a random, complex and 20 chars long password for this service account, you will end up in a binary equivalent cipher strength of 128 bits (which is the maximum complexity of most kerberos implementation). A 128bit key should be secure at least for the next 6-7 years - beyond this timeframe nobody can speak out accurate predictions). Well, you may stir up the things at your security department by asking if they also change the password of the kbrtgt account (the most powerfull account in the kerberos world) exactly 3 times in a row once a year to completly flush the password history of this account (a commom practise if the repository was compromised). If they don't, the security practise in your company wouldn't make much sense...

Cheers, Kai