propagation of new service principal keys

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

propagation of new service principal keys

Jerry Shipman
Hello,

I have seen a (very occasional / pretty minor) problem where:
- 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).
- that problem goes away after a little while after the propagation runs.

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? (that makes sense, I think). It didn't seem to help.

What is the best way to avoid this problem?

I can think of a couple of things:
- 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?
- I can run the propagation more frequently, maybe. It still will have some chance to happen, just a smaller chance? (I have a NAT issue that has, at least so far, prevented me from getting incremental propagation to work.)
- does libkrb5 go through the KDCs in the listed order in krb5.conf? or does it pick a random one from the list? Maybe all I need to do is list the master first on the client? (I don't know why I didn't try that yet.) (It would be nice if the secondaries would take some of the load though, wouldn't it? we also have some geographically-far-apart regions, and maybe it's nice to prefer to go to the closer KDC, except that it happens to be a secondary?)

In practice, this almost never comes up.
But, I wondered what the usual way to prevent this is?

Thanks a lot,
Jerry Shipman
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: propagation of new service principal keys

Ken Hornstein
>- 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 what we do (well, it's automated).  You kind of need to do this
anyway regardless of propagation delay; a cached service ticket can be
hanging around for a long time.

--Ken
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos
Reply | Threaded
Open this post in threaded view
|

Re: propagation of new service principal keys

Greg Hudson
In reply to this post by Jerry Shipman
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
________________________________________________
Kerberos mailing list           [hidden email]
https://mailman.mit.edu/mailman/listinfo/kerberos