[jcifs] NTLM authentication
kevin at tapperson.net
Thu Sep 21 12:24:51 GMT 2006
The NTLMPostFilter described in the link is designed to allow for the proper
handling of HTTP POST operations once NTLM has been negotiated by the
browser with a particular server.
There is a registry setting
Settings/DisableNTLMPreAuth, which controls how IE behaves once NTLM has
been negotiated with a server. Microsoft has implemented a performance
enhancement in IE which prevents IE from sending any POST data to a server
once NTLM has been negotiated with that server. This was done because IE is
assuming that the server will require the browser to re-negotiate NTLM for
the POST request. IE is preemptively assuming that the response from the
server will be a HTTP 401 response and that the server will do no processing
on the request. It therefore does not waste the bandwidth to supply all of
the POST data in the initial request which is sent with the NTLM type 1
message. (This could be considerable savings depending on the actual size
of the POST data.) Once the server rejects the initial POST request from
the browser and responds with the NTLM type 2 message, the browser will
issue a second request containing the NTLM type 3 message along with the
desired POST data. If the registry key is set to 1, this behavior will be
disabled and the browser will submit the POST data with both the NTLM type 1
and NTLM type 3 messages. The default value is 0, which causes IE to only
submit the POST data with the NTLM type 3 message.
The code in the filter examines all HTTP POST requests and determines if
they contain an NTLM type 1 message. If the request contains an NTLM type 1
message, the filter responds with a dummy type 2 message to entertain IE's
desire to re-negotiate NTLM prior to submitting any POST data. The browser
should then respond with an NTLM type 3 message along with the post data
which the filter should then allow to chain to the rest of the web
This filter was designed to work with an active J2EE application behind it
in which the user identity is established on the first attempt to access the
web application and saved in the HttpSession; subsequent accesses to the web
application would not require re-negotiation. If you are using the jcifs
out-of-the-box NtlmHttpFilter, then you don't need to implement this filter.
On 9/20/06, Fahad Sayeed. Siddiqui <fsyeed at xavient.com> wrote:
> This is in regards to the posting which is as below:
> I made the same filter and it works. But suddenly, it stops working and.
> The code is supposed to come in the filter multiple times but after some
> trials, it just comes once and hence, value of pass gets set as true.
> What could be a probable solution?
> Fahad Siddiqui
kevin at tapperson.net
-------------- next part --------------
HTML attachment scrubbed and removed
More information about the jcifs