[OpenAFS] ka-forwarder -> fakeka malformed (bad password)

[Jeffrey Hutzelman]

On Thursday, June 29, 2006 08:08:14 PM -0400 "John W. Sopko Jr." 
<sopko@cs.unc.edu> wrote:

>  >>My Kerberos REALM name and CELL name our DIFFERENT. I need to do this
>  >>since our Windows group took over our the REALM name that is the same
>  >>as the AFS cell name for their Kerberos system.
>
>  >Unfortunately, this puts a bit of a crimp in things.  But it may not be
>  >your real problem.
>
>  >You need to have passwords in the V5 database that AFS can understand.
>  >Do you?  In this case, they probably either need to be V4 salted or AFS
>  >salted .. and if they're AFS-salted, then they probably have the wrong
>  >salt.  And to answer your next likely question ... there's no way to
> convert
>  >keys in the database to ones with the "right" salt.
>
> Is there a way to tell what the salt is? Sounds like there
> is some mix up with the cell name (cs.unc.edu) and the
> kerberos realm name (CXS.UNC.EDU).
>
> The default encryption types for the user are below. Can fakeka handle
> picking out the right one or does there need to be just one
> type specified? I tried setting the single key types
> with "cpw -e des-cbc-crc:v4 sopko" and
> "cpw -e des-cbc-crc:normal" i.e.:
>
> Key: vno 12, DES cbc mode with CRC-32, AFS version 3
> Key: vno 13, DES cbc mode with CRC-32, no salt
>
> and these did not work.

So, you're actually setting two different things: the algorithm used to 
transform the password into a key, and the value of the "salt string" used 
to insure that the same password will result in different keys for 
different principals.

Kerberos V4 and V5 use the same string-to-key algorithm (for single-DES 
keys; other enctypes are unsupported by krb4 except in the case of some 
private extensions).  In V5, the protocol allows the salt string to be 
anything, but the normal value is a concatenation of the principal and 
realm names.  This normal value is what you are selecting with ":normal", 
and is also what kadmin means when it describes a key with "no salt".

AFS uses a _different_ string-to-key algorithm, and uses a salt string 
which is based on both the principal name and the realm (cell) name.  When 
kadmin lists a key with "AFS version 3", it means that this alternate 
algorithm and salt string were used to construct the key.

Now, in krb5, the KDC tells the client what salt string to use, so you can 
do messy things like rename a realm, and still have the keys work. 
However, the kaserver protocol doesn't have this feature -- there is only 
one possible salt string, and the client knows how to compute it based on 
the user and cell names.  It is assumed that the cell and realm names are 
the same, and that the usual case conventions are followed.


_If_ you could get keys into your Kerberos database which were generated 
using the AFS string-to-key algorithm and the _correct_ salt (based on your 
AFS cell name, rather than the realm name), then you should be able to get 
things to work -- assuming there aren't other problems.  Since users are 
being created and changing their passwords all the time, you'd have to 
modify the kadmin and password-changing services to compute keys with the 
correct salt.


Fortunately, you don't need to jump through all these hoops, because AFS 
has supported the "standard" DES string-to-key operation since AFS version 
3.2, released back in 1992.  All you should need to do is get those nasty 
afs3-salted keys out of your KDB, and only use the v4-salted ones.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA