David Pattison david.pattison at siemens.com
Thu Jan 13 16:50:25 GMT 2005

Hi Folks,

Firtly, I apologise for this being more of a jcifs-ext question than a straight
up jcifs one. I only ask here because jcifs-ext has no mailing list and I know
the author hangs about here.

My question is what does the above error mean, and more importantly how to solve
it? All I know is that it involves the Server not being found in the Kerberos
database. Whatever that means. I found it while I was doing an ethereal packet
trace from the client machine. I am in charge of changing our web-app from using
NTLM HTTP authentication over to using Kerberos through the Negotiate protocol,
and as such have implemented the jcifs-ext AuthenticationFilter where the old
NtlmHttpFilter was. I'm pretty sure I'm supplying all the necessary init params,
but I have seen a "principal" mentioned in the source for the filter, although I
dont see how it could be anything to do with the problem. 
The process is as follows:

1- As usual, the client sends its first GET request, which is responded to with
a WWW-Authenticate: NTLM and WWW-Authenticate: Negotiate request.
2- The client then sends the KDC a TGS request (TGS-REQ in Ethereal).
4- The client successfully resends its first request with what seems to be a
valid Negotiate authentication block and gets the desired web page.

Now clearly that error should not be there, as I've seen a successful Kerberos
authentication on my work PC (on another Realm) and all was fine. What I will
also assume is not meant to happen is that the authentication goes through
successfully. Is it actually using Kerberos, or has it reverted to using NTLM
inside a SPNEGO token? Is there any way to actually decode the packets to prove
NTLM or Kerberos/SPNEGO has been used?

Thanks, and apologies for being a newbie.

More information about the jcifs mailing list