Hi Jeff,
Thanks for the reply and effort.
I suspect most of the ancient clients are using "klog" (though
kinit/aklog is an option for most.)
I'm using krb5 with krb-forward on the AFS DB servers.
The existence of the afs/cell@REALM principal is an artifact of an
optimistic attempt to upgrade all clients several years ago, and the
persistent hope that this may still occur. Also I'm not the KRB admin,
though that appears to be in flux.
I'll do some testing on the following ... currently both principals have
the same kvno and only /usr/afs/etc/KeyFile is in play ... and both
principals include des-cbc-crc in their encryption types. And thanks
for the heads up -- I'm still trying to reproduce the configuration that
causes the specific failures ("bad" AFS creds) I was seeing and I've not
tested this case.
If both principals are in use, then they must have different kvnos. The
KeyFile format is not capable of storing multiple keys with the same
kvno.
Kim
On 11/20/2013 2:50 PM, Jeffrey Hutzelman wrote:
On Mon, 2013-11-11 at 08:42 -0700, Kim Kimball wrote:
I've got clients going back as far as Transarc 3.6 -- don't ask ....
there are clients that cannot be changed/rebooted/updated due to
"extreme sensitivity to change."
What software are these ancient clients using to get tokens? klog?
Something else?
In general, if they are using anything based on krb5 and/or krb524, you
can use a stronger service key enctype, no matter how old they are. You
will need to arrange for your KDC to be willing to use DES _session_
keys, because these older clients can't handle anything else.
If they are using something based on krb4 or kaserver, then you have no
choice but to retain the DES service key. In this case, IMHO you are
best off not changing any keys; as long as one AFS service principal has
an active DES key, you gain no security benefit by upgrading the other.
If both principals are in use, then they must have different kvnos. The
KeyFile format is not capable of storing multiple keys with the same
kvno.
I see no benefit to you in using the afs/cellname form, if you still
have clients that will work only with the old form. There are as yet no
clients that do not support the "old-style" principal name. We have
continued to use that name for exclusively here, as we've done for as
long as AFS has used Kerberos-based authentication.
-- Jeff
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
