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