[OpenAFS] KA server to MIT KRB5 migration issues

Marcus Watts mdw@umich.edu
Fri, 07 Nov 2008 15:37:59 -0500

> Date:    Fri, 07 Nov 2008 14:24:30 EST
> To:      "openafs-info@openafs.org" <openafs-info@openafs.org>
> From:    "Derrick Brashear" <shadow@gmail.com>
> Subject: Re: [OpenAFS] KA server to MIT KRB5 migration issues
> On Fri, Nov 7, 2008 at 1:53 PM, Marcus Watts <mdw@umich.edu> wrote:
> > Gedaliah Wolosh <gwolosh@njit.edu> writes:
> > ...
> >>   Is there any way to migrate users from a KA database and authenticate to a
>  KR
> >> B5
> >>   realm with a different name and NOT have every user change their password?
> >>
> >> Sorry for the long post.
> >
> > (the reply will be long too):
> >
> > The AFS3 string to key function uses the cell name as part of the
> > conversion logic.  For klog (with kaserver) that's guaranteed to be
> > the case.
> Nope. OpenAFS moved to des string to key by default a while ago. klog
> tries both, so it "just works".

I know some sites have done that.

The logic for ka_StringToKey in kauth/client.c
is still the afs string to key function.
This is what "bos setkey" and "kas stringtokey" use.

As best I can tell, the logic in kauth/user.c tries ka_StringToKey
first, then des_string_to_key if it gets KABADREQUEST taking to kaserver/fakeka.

kaserver doesn't actually know which string to key function was used,
and yes, if you have the "right" kpasswd, you can use the mit string to
key function.  If it's the openafs default today, that's going to really
complicate Gedaliah's life.  From what he's reported, at least some of
his keys definitely are using the afs3 string2key.  If he's got mit keys
as well, he's going to need a copy of afs2k5db that knows which string
to key function was used on which keys.

Or he may just have to tell his users after conversion time, "change your
password before anything but klog works".

				-Marcus Watts