On Fri, 07 Nov 2014 17:46:19 +0100 Volkmar Glauche <[email protected]> wrote:
> mit-krb5# ktutil > ktutil: rkt /etc/openafs/server/rxkad.keytab > ktutil: l > slot KVNO Principal > ---- ---- > --------------------------------------------------------------------- > 1 0 afs/cell@REALM > 2 0 afs/cell@REALM > 3 0 afs/cell@REALM It seems likely the 0 kvno is the problem. We only copy in a principal if the kvno in the keytab is greater than 'vno' in akimpersonate.c:pick_principal, which starts out at 0. I assume that's valid and we just hadn't encountered this yet? You should be able to workaround it by just bumping the kvno and re-extracting it, so you get a higher kvno. (Or you can just change the kvno in the keytab -- they don't have to be correct -- but that's confusing and don't do that.) I'm not sure if I'll be able to submit a fix before tomorrow; someone else feel free to submit one if you want something today and have the time. > As I already said below, things seem to work fine with this > rxkad.keytab and e.g. aes256-cts-hmac-sha1-96 tokens if the keytab is > brought in place after the servers have been started. Yes, that's because this code path is only hit when we retrieve credentials to use for outgoing connections. That will happen when you -localauth, or when you start up a server, but not if you add these keys to a running server. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
