[OpenAFS] KA server to MIT KRB5 migration issues

Marcus Watts mdw@umich.edu
Fri, 07 Nov 2008 13:53:21 -0500

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.

For your K5 case, that's not guaranteed.  You got klog to work, only
because it doesn't know the kerberos realm is different.  For kinit
and friends, that's not the case.  In that case, the server is telling
the client to use afs3 salt, and the client code then winds up with the
wrong "cellname" for the afs string2key function.

If you want to use stock MIT kdc code, there is no solution.
My guess is that this is most likely true for you.
But, if you are willing and able to make a local modification,
you may be able to achieve your goal.

There are 3 things that matter:
the client side code
the wire protocol
the server side code

The wire protocol is that when you're using AFS 3 salt, the kdc sends
you a KRB5_PADATA_AFS3_SALT preauth item.  This item says "use AFS 3 salt",
and it also contains a "data" string, the "salt".  The kdc may instead
send a KRB5_PADATA_ETYPE_INFO2 which affords the same facility.
This is what makes a solution possible.  The protocol allows you to do
exactly what you want.
{	the kdc may also send KRB5_PADATA_ETYPE_INFO with incorrect data,
	and certain clients will then prefer this to KRB5_PADATA_AFS3_SALT.
	Those clients just won't work. }

For KRB5_PADATA_AFS3_SALT, the client side code marks the request as needing
to use the afs3 string to key function.  The client side code also stores
the salt, if supplied, or supplies a default, if no salt is sent.
Most clients should process the salt sent, but it's possible there
are clients that ignore the salt.  You'll have to test to be sure.

For the server side, there is where your opportunity lies.
Stock MIT code has this comment in krb5/src/kdc/kdc_preauth.c at
around line 1647 (in 1.6.3):
        /* send an AFS style realm-based salt */
        /* for now, just pass the realm back and let the client
           do the work. In the future, add a kdc configuration
           variable that specifies the old cell name. */
This is one place that may be breaking things for you.
Or better yet - instead of the suggested fix, store the actual cell name
in the database (you may need to modify afs2k5db to do this) and
do the same thing as for KRB5_KDB_SALTTYPE_SPECIAL.
You'll probably also have to modify _make_etype_info_entry at about line 1339
where it processes KRB5_KDB_SALTTYPE_AFS3, so that this logic parallels
whatever you did when returning KRB5_PADATA_AFS3_SALT.

Caveat: I haven't tried this, so I cannot guarantee this actually
works right with any client, let alone the clients in your environment.

					-Marcus Watts