[OpenAFS] Question about migration to stronger encryption for AFS
Tue, 5 Dec 2017 13:30:44 -0600
On Tue, Dec 05, 2017 at 05:47:22PM +0000, Sebby, Brian A. wrote:
> I’m working on finally upgrading our AFS cell from DES to stronger encryption keys, and I was able to successfully follow the instructions on the OpenAFS web page to get a new keytab issued for my test cell with stronger encryption.
> However, after installing the new keytab file on my test AFS servers and restarting the processes, I found that tokens that had been issued with my previous key were no longer working - I had to do a kinit with the updated Kerberos principal and run aklog again to get a working token.
> My goal would be to make sure that existing tokens didn’t stop working when I upgrade my production cell, so I’m wondering if I did something wrong or accidentally disabled something too early. Here are the steps I ran:
> 1.) Have new keytab created by our AD admin that has all of the newer encryption types, as well as the older DES encryption, with a new KVNO.
> 2.) Removed the DES keys from the keytab file.
> 3.) Deploy the new keytab file to all of my servers as rxkad.keytab. The old KeyFile was still in place.
The combination of 2 and 3 is probably suboptimal, in that you no
longer have access to the DES key of the new kvno. OpenAFS will
attempt to look for it in the KeyFile when receiving a DES-encrypted
ticket using that kvno, so it's best to keep it in the rxkad.keytab
(even thoug it will not be used from there by AFS; just to keep all
the keys in one place), and also use 'asetkey add' to insert the new
DES key into the KeyFile.
> 4.) Restarted the AFS servers.
> 5.) Ran kinit, and verified that the afs/<cell>@<REALM> key was still listed as des-cbc-crc.
By using kvno(1) or aklog or what? Did the resulting token work?
(I expect it to not work even here.)
> 6.) Had the AD admin unset the ‘DES only’ box on the account tied to the afs/<cell>@<REALM> identity.
> 7.) Restarted the AFS servers again.
> 8.) Ran kinit again, and verified that the afs/<cell>@<REAM> key is now listed as one of the higher encryption types.
Again, via aklog or kvno(1) or otherwise?
> 9.) Ran aklog, verified that I could write to AFS.
> 10.) Tried to write with session that had an older token, and got permission denied. After re-kinit-ing, it worked as expected.
This older token is one from circa step 5?
> I am planning to do the cell upgrade on a weekend to minimize the potential disruption, but I would still like to have my old tokens work if possible. Did I do something wrong or restart any servers too early?
You should be able to get a more seamless upgrade than that, with
old tickets/tokens continuing to work until they expire.