[OpenAFS] Kerberos upgrade logistics

[Marcus Watts]

> Date:    Fri, 13 Apr 2012 15:50:01 EDT
> To:      <openafs-info@openafs.org>
> From:    "Jim Green" <jfgreen@msu.edu>
> Subject: [OpenAFS] Kerberos upgrade logistics
> 
> Hi, folks,
> 
> I made a posting to the Kerberos list on Wednesday and got a couple of
> suggestions to also post here, so here goes:
> 
> At Michigan State, I am leading a project to upgrade our MIT Kerberos
> central authentication service from version 1.6.3 to 1.10.1.  We will be
> dropping support for the Kerberos 4 protocol.  We are a long-time AFS site
> and most of the systems we've been able to identify that still rely on
> Kerberos 4 are either systems that use old AFS clients, or
> systems/applications that have homegrown authentication modules that use
> kaserver. 
> 
> The main drivers for this project are a) desire to support account lockout
> for some users; b) desire to end-of-life Kerberos 4 support as recommended
> in MIT's Kerberos 4 end of life announcement
> (http://web.mit.edu/kerberos/krb4-end-of-life.html).
> 
> I am interested in communicating with folks that have been down this path,
> especially with AFS.  Anyone know of any medium to large research
> institutions running Kerberos 1.7.x or higher with AFS?  If so, I'd
> appreciate contact information.  And, anyone, please chime in if there's
> some reason you know about that makes this idea totally crazy.  Thanks.  PS
> I did get a response from my earlier posting to the Kerberos list that U. of
> Michigan has done something like this, so I've emailed them directly.

Note that "account lockout" is a DOS attack vector.

Dropping k4 & ka is your big problem.  Newer versions of k5 shouldn't
cause you any big problems directly, but there is the chance for subtle
weirdness with very old k5 clients.

kaserver logs what it does - you can use that to detect ka clients &
fix them.

V4 requests via krb5kdc are also logged - handle the same way.

You can turn both of these off w/ 1.6.3 - and if things go badly wrong you
can turn it back on.  That means you can resolve all your k4/ka problems
before even thinking of k5 1.10.1.  To turn k4 off with 1.6.3, on the kdc,
in kdc.conf, [kdcdefaults]
either
v4_mode = none		don't even respond
v4_mode = disable	log & return an error
v4_mode = nopreauth	only for princ's that don't have preauth set.
v4_mode = full		maximum insecurity

Some of your users (at least) probably like klog.  klog and klog.ka
won't work for them once you do this - either train them to use
and like kinit+aklog, or klog.krb5, or link or rename klog.krb5 to
be klog (you can probably just get rid of klog, but you could
call it klog.ka if you're worried.)

For 1.6.3->1.10.1 - that's 2 (maybe 3) efforts.  server (kdc) and
client (end-user/apps).  These can all proceed independently.  For afs,
you'll need "[libdefaults] allow_weak_crypto = 1" on your kdc and clients
that have afs.  You don't need this on clients or app hosts that don't
use afs, and you can generally upgrade clients 1.6.3->1.10.1 piecemeal.
Probably this will go without any problems, but if you have any
very old k5 clients, you might discover problems.

A few more things to watch out for as you upgrade keys: if
you have one version of kerberos doing initial authentication,
and another very different (older?) version getting add'l tickets,
you might run into key type problems.  Typ: getting an AES tgt, then
using a des/des3 only client program.  Try hard to fix the client
rather than putting enctypes into krb5.conf files.

keytabs & srvtabs.  The kdc should never have keytypes for a given
princ that aren't in the keytab for that princ.  If you've
previously made srvtab's from keytabs & visa-versa, you may have
lost encryption types that were in the kdc, which means authenticating
via that keytab probably won't work, at least via clients that
tell the kdc they have that enctype.

If you're doing kerberos 5 with java, there are special problems:
generally, for these you *should* give them their own krb5.conf
file and list enctypes.  The default key order for java k5 is
wrong.  You'll also need to get jce_policy-6.zip that allows AES
w/ kerberos.  Probably available via some unobvious link here,
http://java.sun.com/javase/downloads/index.jsp
Java 1.5 didn't do aes, so, well, avoid it?

				-Marcus Watts