[37888] in Kerberos
Re: propagation of new service principal keys
daemon@ATHENA.MIT.EDU (Ken Hornstein)
Fri Mar 10 13:37:31 2017
Message-Id: <201703101836.v2AIav0s006673@hedwig.cmf.nrl.navy.mil>
From: Ken Hornstein <kenh@cmf.nrl.navy.mil>
To: Jerry Shipman <jes59@cornell.edu>
In-Reply-To: <8DDB8C46-5902-41A3-979A-B9E0440415A0@cornell.edu>
MIME-Version: 1.0
Date: Fri, 10 Mar 2017 13:36:56 -0500
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
>- 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 Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
