[OpenAFS] Re: OpenAFS 1.6.5/1.6.10 - server segfaults during migration to rxkad-k5

[Benjamin Kaduk]

On Mon, 10 Nov 2014, Andrew Deason wrote:

> On Mon, 10 Nov 2014 14:24:49 +0100
> Volkmar Glauche <volkmar.glauche@uniklinik-freiburg.de> wrote:
>
> > I've never used kaserver/kerberos4, but maybe I followed installation
> > guidelines that still had kaserver in mind and proposed kvno=0.  Would
> > bumping the kvno affect existing tokens/Keyfiles that are still
> > relying on kvno=0? If so, I'll have to postpone keytab installation
> > until I find a maintenance time slot.
>
> For specifically rxkad.keytab (i.e. non-DES) processing, we mostly
> ignore the kvno for incoming connections, so this shouldn't break
> anything and you should be okay (checking the kvno only changes the
> error we return if we can't find a working key).

Well, it behaves the same as any kerberized (clustered) service during key
rollover: with the current implementations, the KDC generates a new key
and transmits it to the entity making the key change and starts issuing
tickets using that new key.  Existing tickets (tokens) continue to work
just fine, but tickets that are issued in the time window between when the
KDC generates the new key and when the new keytab is installed on (all of
the cluster's) servers will fail, until the new keytab is installed.

There are alternate algorithms and technologies which can or could work
around this race window, but they are not yet part of the standard
workflow.

-Ben