Dear Benjamin, dear Andrew, dear list,
thank you very much for discussing the details of this keytab problem.
The kvno in the kdc is indeed zero. I don't remember how this
happened. Since we have been working without rxkad-k5 since now, my
solution is to rectify the kvno issue by rekeying during the next
scheduled maintenance window.
Best regards,
Volkmar
Zitat von Benjamin Kaduk <[email protected]>:
On Mon, 10 Nov 2014, Andrew Deason wrote:
On Mon, 10 Nov 2014 22:23:51 -0500 (EST)
Benjamin Kaduk <[email protected]> wrote:
> On Mon, 10 Nov 2014, Andrew Deason wrote:
>
> > On Mon, 10 Nov 2014 14:24:49 +0100
> > Volkmar Glauche <[email protected]> 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:
This is true if the key actually changes. I interpreted Volkmar's text
to mean that Volkmar would (hypothetically) just change the kvno in the
keytab only. Since we don't verify the kvno provided by clients against
the kvno in our rxkad.keytab (in this specific situation), I believe
that should work with no downtime.
Ah, I had read it a different way.
Yes, I agree that using (e.g.) ktutil to make a keytab that contains the
same key with both kvno 0 and 1 should solve this issue without an outage.
Probably just replacing rxkad.keytab with a version of kvno 1 (and no kvno
0 copy) would also work, but I'd have to think about it a bit more to be
sure.
Sorry for increasing the confusiong...
-Ben
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Freiburg Brain Imaging
http://fbi.uniklinik-freiburg.de/
Tel. +761 270-54783
Fax. +761 270-54819
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
