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

[John W. Sopko Jr.]

Thanks for the info. I set my encryption type to:

kadmin: cpw -e des-cbc-crc:v4 sopko

which produces the output from kadmin as:

Key: vno 16, DES cbc mode with CRC-32, Version 4

I get a different error on the k5/fakeka server when
trying to do an AFS klog:

Jun 30 08:19:37 kfive fakeka[18668]: authenticate: sopko. from 152.2.128.185
Jun 30 08:19:37 kfive fakeka[18668]: ... failed due to request was malformed 
(bad password)
Jun 30 08:19:37 kfive fakeka[18668]: authenticate: sopko. from 152.2.128.185
Jun 30 08:19:37 kfive fakeka[18668]: principal krbtgt.CS.UNC.EDU does not exist
Jun 30 08:19:37 kfive fakeka[18668]: getticket: Unknown.Unknown from 
152.2.128.185 for afs.

looks like fakeka wants a K4 style user.instance name for
"krbtgt.CS.UNC.EDU". I checked the production afs cell
with "kas list" and the instance does exist. Or maybe
fakeka would be happy with the k5 style principal krbtgt/CSX.UNC.EDU@CSX.UNC.EDU
if the REALM name and Cell name were the same.

The output from "fakeka -d" is:


# ./fakeka -d -f eagle.cs.unc.edu

Handling Authenticate request
Authenticating sopko.
Handling Authenticate request
Authenticating sopko.
Handling GetTicket request
Cell is CS.UNC.EDU
Request for afs/


I am just testing and trying to put together a migration plan.
I could move the k5 server to the afs db server and run fakeka
their if we think the problem is in the ka-forwarder but it
sounds like the problem is with the REALM name being different
from the cell name.


Jeffrey Hutzelman wrote:
> 
> 
> 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
> 

-- 
John W. Sopko Jr.               University of North Carolina
email: sopko AT cs.unc.edu      Computer Science Dept., CB 3175
Phone: 919-962-1844             Sitterson Hall; Room 044
Fax:   919-962-1799             Chapel Hill, NC 27599-3175