> Could you look at the salt that is being used? The easiest way to do > that is to try sending an AS request and see what you get back in the > etype-info structure?
I have done some investigation now and have the following information. The Active Directory Domain (Kerberos realm) is DEV.PROPERO.INT. It is running Windows 2003 Active Directory. The account in question is "paeuser1" with password "secret�" (secret following by a pound sterling (0x00a3 in Unicode)). The account requires pre-authentication. Logging into a domain-connected Windows client PC works. Performing an LDAP bind (from Java) to AD using this username and password also works. Therefore the password really is what we expect. The client code is jKrb5 (from http://www.mit.edu/afs/athena/astaff/project/krb5/raeburn/jkrb5 with a few fixes and additions). References: crypto spec: draft-ietf-krb-wg-crypto-07.txt kerberos spec: draft-ietf-krb-wg-kerberos-clarifications-06.txt 1) Confirming the salt Sending a non-preauthenticated AS_REQ message results in a KRB_ERROR message of type KDC_ERR_PREAUTH_REQUIRED. The associated e-data contains a sequence of PA-DATAs as follows: Type Name Value 11 pa-etype-info etype=1, salt="DEV.PROPERO.INTpaeuser1" 2 pa-enc-timestamp No data (e-data block is 0 length) 15 ??? No data (e-data block is 0 length) Ethereal shows the following KRB-ERROR e-data block (starting at position 0x94): 0090 4e 54 ac 49 04 47 30 45 30 2d a1 03 02 01 0b a2 NT.I.G0E 0-...... 00a0 26 04 24 30 22 30 20 a0 03 02 01 01 a1 19 04 17 &.$0"0 . ........ 00b0 44 45 56 2e 50 52 4f 50 45 52 4f 2e 49 4e 54 70 DEV.PROP ERO.INTp 00c0 61 65 75 73 65 72 31 30 09 a1 03 02 01 02 a2 02 aeuser10 ........ 00d0 04 00 30 09 a1 03 02 01 0f a2 02 04 00 ..0..... ..... So, without understanding the other e-data PA-DATA elements, it seems that the default salt is correct: DEV.PROPERO.INTpaeuser1. 2) Confirm the string_to_key being used A test harness for the string_to_key() function has been developed to test that the function is operating correctly (according to the crypto spec). Three string_to_key functions were tested: 1 Original (the original jKrb5 function modified to use UTF-8 password to bytes encoding) 2 Boolean[64] (a direct re-implementation of the original function using arrays of booleans instead of Java longs for the bit manipulation. This includes the various left and right shift operations from the original implementation.) 3 Boolean[56] (a direct implementation of the spec using arrays of booleans for the bit manipulation. Instead of working on 64 bits, this implementation follows the spec precisely and only operates on 56 bit bitstrings.) Note: The left and right shifts in the original string_to_key() puzzled me for a while as they are not in the spec. However, it is clear that they are just a optimisation of the algorithm. During the tests, all three algorithms give exactly the same output, so I'll only give results for the original algorithm. Four sample results are used (the full source is shown: password + realm + username): 1 Simple password RESULT ----------------------------------------------------- RESULT Password: secretDEV.PROPERO.INTpaeuser1 RESULT Bytes: 73 65 63 72 65 74 44 45 56 2e 50 52 4f 50 45 52 4f 2e 49 4e 54 70 61 65 75 73 65 72 31 RESULT Method: Original RESULT Generated: 40d586a1d51f6294 RESULT Wanted: 40d586a1d51f6294 RESULT Outcome: PASS RESULT ----------------------------------------------------- 2 Pound sign in password RESULT ----------------------------------------------------- RESULT Password: secret<A3>DEV.PROPERO.INTpaeuser1 RESULT Bytes: 73 65 63 72 65 74 c2 a3 44 45 56 2e 50 52 4f 50 45 52 4f 2e 49 4e 54 70 61 65 75 73 65 72 31 RESULT Method: Original RESULT Generated: 76f72392310e62bc RESULT Wanted: 202ba9bfe70ad37 (from ktpass) RESULT Outcome: FAIL RESULT ----------------------------------------------------- 3 Simple test case from crypto spec RESULT ----------------------------------------------------- RESULT Password: passwordATHENA.MIT.EDUraeburn RESULT Bytes: 70 61 73 73 77 6f 72 64 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 72 61 65 62 75 72 6e RESULT Method: Original RESULT Generated: cbc22fae235298e3 RESULT Wanted: cbc22fae235298e3 RESULT Outcome: PASS RESULT ----------------------------------------------------- 4 Complex test case from crypto spec: "<A7>ATHENA.MIT.EDUJuri?i?" RESULT ----------------------------------------------------- RESULT Password: <A7>ATHENA.MIT.EDUJuri?i? RESULT Bytes: c3 9f 41 54 48 45 4e 41 2e 4d 49 54 2e 45 44 55 4a 75 72 69 c5 a1 69 c4 87 RESULT Method: Original RESULT Generated: 62c81a5232b5e69d RESULT Wanted: 62c81a5232b5e69d (from crypto spec) RESULT Outcome: PASS RESULT ----------------------------------------------------- 3) Windows ktpass Using ktpass.exe on Windows I generated the following keys: 1 Simple password: 0x40d586a1d51f6294 2 Pound sign in password: 0x0202ba9bfe70ad37 3 Simple test case from crypto spec: 0xcbc22fae235298e3 4 Complex test case from crypto spec: 0xe65d5238b96bf245 Note: In case 4, I'm not sure I was able to pass ktpass.exe the right characters... I created a batch file (saved in UTF-8 encoding) that used variables to substitute the username and password on the command line. I used the Character Map utility to enter the characters into the batch file in the first place. In both cases where non-7-bit-ASCII characters are used ktpass.exe generates a different key from the MIT standard. 4) MIT Kerberos 1.3.4 Running MIT Kerberos 1.3.4 from Linux with the paeuser1/secret� combination also failed. Note: I could not type a pound sign on the command line, but could edit a file containing one, using it as follows: ditty:bin$ ./kinit -V [EMAIL PROTECTED] < password Password for [EMAIL PROTECTED]: kinit(v5): Preauthentication failed while getting initial credentials 5) Summary It seems that our client code is correct w.r.t. to the draft Kerberos and crypto specs, however MS AD is producing/expecting different keys for non-7-bit-ASCII passwords even though the salt is the same. Any ideas on where to go next? Thanks, Frank. ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
