I would reply inline, but Outlook is being uncooperative, so to reply to your questions:
I used ‘kinit -e’ to see what encryption type was being used for the afs/<cell>@<REALM> token when I did the aklog. The kvno of the older DES keys that had issued the older tokens was kvno = 6, while the new keys have kvno = 7. I did not replace the DES keys in the KeyFile with the kvno = 7 DES keys since I assumed that the older tokens would need to be decrypted using the kvno = 6 key. I don’t really need the DES version of the kvno = 7 key going forward, since my main concern is for the ~10 hours or so that any existing tokens may still be used, especially for a few longer-running processes that use AFS. Worse comes to worse, I can just restart a few things that need to access AFS and tell users to re-authenticate. Brian -- Brian Sebby ([email protected]) | Information Technology Infrastructure Phone: +1 630.252.9935 | Business Information Services Cell: +1 630.921.4305 | Argonne National Laboratory From: Benjamin Kaduk <[email protected]> Date: Tuesday, December 5, 2017 at 1:30 PM To: "Sebby, Brian A." <[email protected]> Cc: openafs-info <[email protected]> Subject: Re: [OpenAFS] Question about migration to stronger encryption for AFS 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. -Ben
