AFS Krb5 Migration

AFS Kerberos 5 Migration

This page describes NCSA's conversion from AFS kaserver authentication to Kerberos 5 authentication. It lists why we did it, how we did it and problems we ran into along the way.

Overview of NCSA Environment and Goals (Why we did it)

NCSA has a production AFS cell (ncsa.uiuc.edu) which was used for authentication as well as NCSA's primary distributed filesystem across a large number of machines. There were also a number of unix machines which used local password files (/etc/passwd) due to a lack of native AFS clients for their particular operating system. NCSA also has a number of PCs running Windows 95 and NT that currently used a NT server of authentication. Macintoshes were phased out and not addressed by this plan.

We were looking for a secure authentication mechanism that could be used for almost every host (if not every host), and a means to have one time authentication. We liked alot of the features of Kerberos 5, and as the successor to kerberos 4 (which is the authentication scheme used in AFS), it would work well in our environment.

Features of Kerberos 5:

Passwords are never sent over the network. You use kerberos to obtain tickets that give you access to systems or services. Tickets are sent over the network encrypted to prevent malicious third parties from sniffing sensitive data and being about to fake authentication.
Authentication with kerberos is done with electronic tickets which can be forwarded from one host to another. Once you authenticate yourself to kerberos once and get a ticket, you can not only use the ticket to gain access to a remote host, but you can forward your ticket to the host so that you can access other hosts from that host. This means you only have to authenticate yourself once.
A kerberos 5 ticket can be converted into an AFS token. Since AFS authentication is based on Kerberos 4, it is possible to convert a copy of your kerberos 5 ticket into an AFS token. When you combine this with the fact that you can pass a copy of your kerberos ticket to another host, it can automatically get you an AFS token on that host.
Kerberos has a central user database. With kerberos there is what is called a KDC (Key Distribution Center) that authenticates users and hands out tickets. This allows for once central database of users.

Along with the above it was gaining momentum from other sites using it. Which usually would mean better supported and more services available.

So we developed a plan of how Kerberos 5 can be deployed at NCSA in such a way to provide a common secure authentication mechanism for almost all of NCSA's systems, work smoothly with AFS, and provide one-time authentication so that users do not have to authenticate themselves repeatedly or resort to .rhosts files.

Deployment Plan (How we did it)

Von Welch was tasked with setting up and testing Kerberos 5 starting in January of 1997. He initially started with the MIT Kerberos distribution and a patch from Doug Engert of ANL which incorporated modifications to work with AFS. Soon after working with the ANL patches he became aware of some work by Ken Hornstein of NRL. Ken was developing a AFS/Krb5 Migration kit for sites that were converting from AFS style authentication to Kerberos 5. Since our site was doing exactly that we started incorporating the NRL patch into our Kerberos test environment.

One note to mention here. We decided to name our Kerberos 5 realm (NCSA.EDU) different than our AFS cell (ncsa.uiuc.edu). Why? Well, we thought it a good idea at the time because of the direction NCSA was going. However, after going through much of the testing, and looking back on the decision, we would STRONGLY reccommend to anyone NOT to do this. We ran into numerous problems which are described in the Problems section below.

After a number of months of testing Kerberos and the migration kit, reporting bugs/fixes to Ken, and retesting we had a stable Kerberos test environment. We started having core NCSA users test the NCSA realm in the Fall of 1997. By the end of the year we had done quite a bit of testing with our realm and were ready to deploy it site wide at the first of the year.

So on January 4, 1998, we did one last conversion of our AFS kaserver database to a Kerberos 5 database and shut down the kaserver. We have been using Kerberos 5 in the place of the kaserver ever since.

Problems we ran into

As I mentioned above, the number one problem we had was naming our realm different than our cell name. There were quite a few coding changes that needed to be done, particularly with respect to getting an AFS token from a Kerberos 5 credential. The reason for this follows.

Basically what needs to happen is that you want to end up with a K4 ticket for afs@ncsa.uiuc.edu. This principal is actually stored in the k5 database as afs/ncsa.uiuc.edu@NCSA.EDU. So what happens is fakeka or aklog requests a k5 ticket for afs/ncsa.uiuc.edu@NCSA.EDU and then uses krb524 to convert that into a k4 ticket. Some magic happens here because we have mods to krb524/conv_princ.c that when an afs ticket gets converted it massages afs/ncsa.uiuc.edu@NCSA.EDU into afs@ncsa.uiuc.edu. So when fakeka or aklog gets the ticket back from krb524d it's got the right service principal in it.

Then there was the problem of how the key was salted. The basic issue is that the principals in AFS are salted with the cell name (actually, the Kerberos realm name of your AFS cell, which is just the cell name uppercased). When the client utilities create the encryption key from your password, the wrong salt will be used, and the wrong key will be generated. There is room in the KDC to store the name of an alternate salt. By default, "afs2k5db" will store the name of the current realm in the database, but this can be changed. Thus you can give the name of the Kerberos realm of your AFS cell to "afs2k5db" and it will be stored in the database.

Another big problem we ran into once we set up the kerberos 5 server as a production server was that none of the Windows boxes could get tokens any longer. The reason for this is the afs implementation under windows has special problems. Unlike the unix afs implementation it does not talk KA but instead talks k4 directly, so it doesn't go through fakeka or krb524. It instead talks directly to the kdc so that none of our magic hooks in krb524 get invoked. So what we had to do is get aklog working under windows. We then have users use the k5 credentials manager for the windows client to get a k5 ticket, it will then automatically run aklog and get them an AFS token.

If you take a look at the AFS-KRB5 migration kit it has additional documentation on this transition along with lots of great explanations of what goes on and how things work.

Back to NCSA Kerberos Information

Questions or comments about this page may be sent to kerberos@ncsa.uiuc.edu