[jcifs] No response to NTLM challenge

[Steven.Durkin at scotland.gsi.gov.uk]

*******************************************************************************************************************************************************
This email and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed.
*******************************************************************************************************************************************************

Eric,

I have finally managed to get the time and necessary tools to try out
the changes you suggested. Apologies for the delay. I have detailed the
results from that below. 

The problem I have is that the client fails to send a type 3 response in
answer to a type 2 message from the server, and I noticed a posting from
March 2003 showing a problem with Windows 98 /IE6. (Thread subject: NTLM
+ TOMCAT + WINDOWS 98 (IE6) combination) This is similar to us in that
the problem here emerged after an upgrade to XP / IE6 from NT4 / IE5.5.
I have got hold of a machine running our old spec NT4/IE5.5 machines and
run a trace, but I haven't yet spotted any significant difference
between packets from this and packets from a new spec XP/IE6 machine. I
can provide copies of the packet captures from the old spec machine if
you would like to see them. 

I must admit I am a bit stuck on what to look at next. I'm wondering if
there are any client side settings that I should check? Could you
suggest anything?

In the meantime here are the results from your previous suggestions:

> 1) Try the request against Tomcat directly (rather than going through
> the mod_jk connector).  

Working against tomcat directly doesn't send an empty body for me (I
still get content returned with the challenge message) But the behaviour
overall *is* modified. Under Coyote the client responds with a simple
GET request as it did under Apache/mod_jk, (i.e. no type3 message
generated). However while the response from the server is still a 401 as
before, the client then attempts to negotiate an NTLM authentication
process for a second time before going silent. (Under apache/mod_jk the
client went dumb after the second 401 from the server.) I can provide
copies of packet captures from this transaction if you require them.

> 
> 2) We shouldn't have to hardcode a 0 content length; chunked encoding
> appears to work fine.  This is a preferable approach, as it would
> allow for any error content that the container happens to append to
> the response.  The attached version has the fix applied; see if this
> works under the mod_jk connector.
> 

I compiled new classes from the source in jcifs-0.9.6.zip, replacing
NtlmSsp.java with the copy you emailed me, but although the header no
longer includes "Content-Length" I got no overall change in behaviour -
IE6 does not send a type 3 response.

Thanks for your support on this, it is much appreciated. If I can
provide any further information then let me know and I will do my best
to provide it,

Steve.

The original of this email was scanned for viruses by the Government Secure Intranet (GSi) virus scanning service supplied exclusively by Energis in partnership with MessageLabs.

On leaving the GSi this email was certified virus-free