[OpenAFS] incorrect KeyFile causing cell setup to fail -- maybe
wrong enctype ? [SOLVED]
Tue, 13 Mar 2007 20:00:51 +1300
a big thanks to those who responded to this one. in-between starting a
new job i managed to sort all this out. basic issue was to remove all
unnecessary enctypes & then bob's your uncle.
NB in case anybody needs to refer to something more concrete about what
was done, here is the working procedure:
kadmin -p admin/krb
kadmin> add --random-key --use-defaults afs/muse.net.nz
kadmin> del_enctype afs/muse.net.nz des3-cbc-sha1
kadmin> del_enctype afs/muse.net.nz aes256-cts-hmac-sha1-96
kadmin> del_enctype afs/muse.net.nz arcfour-hmac-md5
kadmin> list *afs*
kadmin> get afs/muse.net.nz@MUSE.NET.NZ
Principal expires: never
Password expires: never
Last password change: never
Max ticket life: 1 day
Max renewable life: 1 week
Last successful login: never
Last failed login: never
Failed login count: 0
Last modified: 2007-03-12 04:28:42 UTC
Keytypes: des-cbc-md5(pw-salt), des-cbc-md4(pw-salt),
kadmin> ext -k /etc/afskeytabfile.krb5 afs/muse.net.nz
root@ice:/ $ ktutil -k /etc/afskeytabfile.krb5 list
Vno Type Principal
1 des-cbc-md5 afs/muse.net.nz@MUSE.NET.NZ
1 des-cbc-md4 afs/muse.net.nz@MUSE.NET.NZ
1 des-cbc-crc afs/muse.net.nz@MUSE.NET.NZ
root@ice:/ $ mkdir -p /usr/afs/etc
root@ice:/ $ ln -s /etc/afs/ThisCell /usr/afs/etc/ThisCell
root@ice:/ $ cat /etc/afs/ThisCell
root@ice:/ $ ktutil copy FILE:/etc/afskeytabfile.krb5
NB i'd be happy to add this to the wiki in future, but i'll wait until
openbsd 4.1 comes out (& we get the openafs port added into -current
again) as there are further kerberos/heimdal changes within apparently
to catch me unawares.
> * ted creedon [2007-03-09 07:35:12 -0900]:
>> Kadmin needs "des-cbc-crc:normal" specifically with the ":normal" suffix.
heimdal desalinates (ok removes the salt) on export. nice!
> N.B. scorch is using Heimdal (0.7 or 0.8?), not MIT Kerberos.
> I'd suggest deleting the AES and Arcfour enctypes as well. This was
> probably not an issue with the version of Heimdal in use three years
> ago (no AES support yet), which would explain why those old notes did
> not mention it.
> "bos listkeys" lists two keys with the same kvno (1). At least one of them
> must be wrong.
yes :-) good question how _that_ got in!
the next big task is to figure out how to build openafs with files going
into the "right" place according to openbsd hierarchy. this used to work
as part of the old port, but it's not doing the right thing at present.