> Date: Fri, 13 Apr 2012 15:50:01 EDT > To: <[email protected]> > From: "Jim Green" <[email protected]> > 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 _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
