[OpenAFS] aklog vs referrals

[John Tang Boyland]

] * 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
]       exists).

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
      kadmin
	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.)

John