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/[EMAIL PROTECTED]
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."
<[EMAIL PROTECTED]> 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) <[EMAIL PROTECTED]>
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
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
