[OpenAFS] aklog vs referrals
John Tang Boyland
Fri, 21 Dec 2007 13:30:49 -0600
] * John Tang Boyland [2007-12-20 08:50:32 -0600]:
] > Can someone describe the steps necessary to effect this change? We
] > migrated our cell to kerberos V two years ago but still use the
] > afs@REALM shorthand. I would expect that the change involves some
] > add_principal and ktadd commands and maybe asetkey and copying
] > super-secret files around,
] That's about right. The KDC-side details depend on which brand of KDC
] you are using, so I can't be too specific. Note that the procedure is
] essentially the same as for ordinary AFS cell rekeying, which you ought
] to be doing once in a while (it doesn't take very long to brute-force
] DES keys any more, certainly much less than two years).
OK. I'll get on it.
We're using MIT kerberos 1.5.4 (patched) so ktutil doesn't have all
those nifty options.
] Ideally you'd do things in this order:
] 1) generate a new single-DES key;
] 2) add it to your AFS keyfile, with a new kvno;
] 3) distribute the updated keyfile to all your AFS servers;
] 4) add the corresponding principal to your realm, with the single-DES
] key you stored into the keyfile (and the same kvno) --- or, for routine
] rekeying, replace the existing principal's key and kvno with the new one.
] 5) for routine rekeying: wait one maximum token lifetime before deleting
] the old key from the AFS keyfile. Repeat step 3 afterwards.
] Unfortunately the available tools encourage you to do it in the order
] 1-4-2-3, which can cause trouble for anyone who obtains a token after
] step 4 and tries to use it before step 3; so you should do it quickly
] and at a time when no one is requesting new tokens. Some KDCs may let
] you add the key (step 4) without making it "live" until some later time;
] I've heard there are (were? maybe it's done) plans to add this feature
] to MIT Kerberos at least.
I don't see this option in our (older) version of MIT Kerberos.
] You can automate step 3 with the upserver/upclient tools. For step 2 you
] have a choice between asetkey, Heimdal's ktutil, "bos addkey" and
] rolling your own tool.
] I use Heimdal as the KDC, and according to my notes the procedure is:
] 1. Generate a new DES key on the master AFS server, store it in a
] temporary keytab. The command we used was:
] ktutil -k afs.keytab add -p afs/astro.su.se -V 1 -e des-cbc-crc -r
] The key version number should be one more than the current value
] for this principal.
] 2. Add the key to the AFS keyfile:
] asetkey add 1 afs.keytab afs/astro.su.se
] (again, after adjusting the key version number).
] 3. Wait for the AFS keyfile to propagate to all servers. One can use
] bos listkeys 'server' -localauth
] to verify that the named server has been updated.
] 4. Use asetkey list to get the 16-byte hexadecimal string
] representation of the new key. This can also be extracted from the
] keytab using
] ktutil -k afs.keytab list --keys
] 5. Add the new key to the KDC database:
] kadmin add --key='hexvalue' afs/astro.su.se
] (replacing add with cpw if the afs/astro.su.se principal already
Without Heimdal's ktutil, I can't use the asetkey approach (unless I
use ktadd -- doing step 4 first).
Perhaps it seems I could try to do "bos addkey", but MIT kadmin addprinc
doesn't permit a "-key" flag. Can I "bos addkey" and then "addprinc"
with the same password assuming I choose the salt exactly right?
Will bos use the same algorithm as MIT addprinc? This seems very risky.
So it seems the only alternative is
ktadd -k afs.keytab afs/cs.uwm.edu -e des-cbc-crc:v4
asetkey add V afs.keytab afs/cs.uwm.edu
and then wait for propagation (or copy files "real fast" since
upclientetc will hose the fileserver, see below).
I assume that I need ":v4" but perhaps newer version of OpenAFS don't
need this? Or do I use "normal"?
] This is how I successfully switched from afs@ASTRO.SU.SE to
] afs/astro.su.se@ASTRO.SU.SE. My previous kvno was 3 or 4, so I was able
] to restart from 1; that made the procedure somewhat simpler in step 5.
] > but I'm afraid if I tried to do it myself,
] > I would get a kvno problem and the fileservers would stop working
] > and/or it would be impossible to get AFS tokens.
] Set up a test cell and practice until you have it all ironed out.
Indeed. This area is FRAUGHT with pitfalls. For example,
in preparation for the transfer, I started up upserver -crypt
/usr/afs/etc and upclient /usr/afs/etc to propagate any changes, and
suddenly the fileservers started getting
afsconf_GetKey failure: kvno 1 code
errors EVEN THOUGH the key files were previously identical on all
machines and STILL were identical. The files were binary the same
before and after. I had to stop the upclientetc
processes and restart the fileservers to stop having all tickets
discarded. (The file servers are running OpenAFS 1.4.1 and the
control machine 1.2.8)
] > If it helps,
] > there's nothing wrong with leaving the old afs@REALM principal alive
] > and working.
] Of course you should do that. You can then monitor your KDC's logs and
] see who is still using the old principal once you've introduced the new
] one. (In my case there were a few old clients that preferred the
] null-instance principal. I investigated and found that they *could*
] use the afs/cell.name principal if the other one wasn't available,
] after which I eventually removed the old principal. But there is no
] hurry, as long as you rekey both principals regularly.)