[OpenAFS] ka-forwarder -> fakeka malformed (bad password)
Thu, 29 Jun 2006 20:48:27 -0400
On Thursday, June 29, 2006 08:08:14 PM -0400 "John W. Sopko Jr."
> >>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
> >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
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
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) <email@example.com>
Sr. Research Systems Programmer
School of Computer Science - Research Computing Facility
Carnegie Mellon University - Pittsburgh, PA