EricLaw said:The "Firefox-ntlm.pcap" file you've sent contains only traffic with an IE10/Trident6 UA string. There's no mention of Gecko anywhere.
the webapp does a check for the useragent, so for troubleshooting pruposes I made Firefox pretend it was IE10, but the dump is actual Firefox traffic. Sorry for the confusion.
The captures you've sent me show that IE is, in fact, responding to the initial WWW-Authenticate: NTLM message with a Type-1 request message (use the Auth request and response Inspectors in Fiddler to see this). The server then returns a Type-2 response message (TCP/IP FIN) and closes the connection before the client can send the Type-3 request message that completes the NTLM handshake and authorizes the connection.
I'm 95% sure that the problem here is that the server is closing the connection after returning the Type2 NTLM Challenge message. NTLM requires keep-alive connections to function properly; closing the Connection isn't compatible with that. (This is consistent with the http://davenport.sourceforge.net/ntlm.html#ntlmHttpAuthentication documentation that you mentioned; the connection is expected to be reused after the server's Type2 challenge.)
Make that 100%!!!
Turns out that the webapp uses an apache reverse proxy, on the same server, which was misconfigured by our supplier:
after commenting out the erroneous entries, ntlm is working as it should
Thanks a lot, your help is really appreciated.
The least I can do is buy your book, but if you have a tip jar I'll gladly donate you some bucks.