propagation of new service principal keys

[Greg Hudson]

On 03/10/2017 01:10 PM, Jerry Shipman wrote:
> - a service admin rekeys a service principal, and puts the new keytab on his server
> - a user/client gets a service ticket for that service, but from a secondary KDC to which the new service key has not yet propagated
> - when the user gives the service ticket to the service, he gets "-1765328154: Unknown code krb5 230", which is maybe KRB5_KT_KVNONOTFOUND (kvno mismatch).

This isn't necessarily just a KDC propagation issue; a client could
simply have a cached ticket encrypted in the old service key.

> I optimistically tried to fix this by adding a "master_kdc" line to the client's krb5.conf, but, maybe that only applies to TGTs and not to service tickets? 

Master KDC fallback only applies to initial ticket requests.  It ought
to also apply to TGS requests [1], but that wouldn't help here, because
the TGS request to the secondary KDC doesn't fail.

> - service admin can put in a second/new keytab that has both keys, wait some length of time, then put in a third/new keytab that has just the new key. It's an extra step for the service admin, though?

This is the usual approach.  "k5srvutil delold" can be used to remove
the old keys from the keytab when they are no longer needed.

There is also a window where the client gets a ticket encrypted in the
new service key before the new key is stored in the service's keytab
file [2].  With the normal kadmin tools this window is small but remains
unaddressed.  Roland's krb5_admin tools [3] are one way to eliminate it.

[1] http://krbdev.mit.edu/rt/Ticket/Display.html?id=5338
[2] http://krbdev.mit.edu/rt/Ticket/Display.html?id=5339
[3] http://oskt.secure-endpoints.com/krb5_admin.html