Hu guys,
I'm currently setting up a J2EE web-app to use Kerberos via HTTP (by using the jcifs-ext package, which uses JAAS and JGSS through the Negotiate protocol), but after an age of finding out how everything should be set up, I've hit a problem at what I think is the last stage.
Basically the problem is that whenever I run the app, I receive a GSSException, specifically: "Failure unspecified at GSS-API level (Mechanism level: KDC has no support for encryption type (14)".
I'm assuming that this is something to do with Windows Active Directory and Java only being able to communicate via DES encryption. I think its the KDC not being able to decode the messages, but I am positive AD is all set up fine. All the principals and users are set up to use DES encryption and have had their password hashes reset and the krb5.conf file specifies des-cbc-crc and des-cbc-md5 for the ticket encoding. But then again a look at the event log reveals inconsistent KDC errors saying the client and server did not have a suitable key for generating a kerberos ticket. It suggests I reset the passwords if the encryption type is valid (which I think it is), but this doesn't make any difference.
Below is the stack trace (I'll bet you were looking forward to seeing it). The only things I can see that cause concern is the "DsGetDcName returned 1355", "Found no TGT's in LSA" and "null credentials from ticket cache". I know that the first means that the DC wasn't located though DNS, which is disconcerting, but then an Ethereal capture clearly shows that the DC specified in the config files is being found. In fact the capture shows that there are no errors in getting the tickets and authenticating. The SPNEGO encryption looks correct and is sent to the client, but is responded to with the stack trace below. Specifically, the app server gets an AS-REQ followed by an AS-REP. The client has the same but followed by a TGT-REQ and TGT-REP, however the client traffic is received in des-cbc-md5 encryption and the server traffic is in des-cbc-crc format. No mention of a Kerberos encryption error. Would this difference be the problem, or would it in any way prevent the server from sending its TGS-REQ? I've tried setting krb5.conf to only 1 of them, and both, but no difference.
Any help would be greatly appreciated. I'm using Win2K pro on the client and server and Win 2K Server on the DC, as well as Java 1.4.1_07 (is this where the problem lies?) and J2EE 1.4.
Debug is true storeKey true useTicketCache true useKeyTab true doNotPrompt false ticketCache is null KeyTab is C:\kerbwebserv.keytab principal is HTT
P/kerbwebserv.realm.com@REALM.COM tryFirstPass is false useFirstPass is false storePass is false clearPass is false
KinitOptions cache name is C:\Documents and Settings\kerbadmin\krb5cc_kerbadmin
KeyTab: load() entry length: 67
KeyTabInputStream, readName(): REALM.COM
KeyTabInputStream, readName(): HTTP
KeyTabInputStream, readName(): kerbwebserv.realm.com
EType: sun.security.krb5.internal.crypto.DesCbcMd5EType
KrbAsReq calling createMessage
KrbAsReq in createMessage
KrbAsReq etypes are: 1
KrbKdcReq send: kdc=137.223.232.22, port=88, timeout=60000, number of retries =3, #bytes=245
KrbKdcReq send: #bytes read=1327
EType: sun.security.krb5.internal.crypto.DesCbcCrcEType
crc32: 36da72b6
crc32: 110110110110100111001010110110
KrbAsRep cons in KrbAsReq.getReply HTTP/kerbwebserv.realm.com