[jcifs] NTLM authentication

Mike Kienenberger mkienenb at gmail.com
Thu Sep 21 19:43:22 GMT 2006


I've written a subclass of NtlmHttpFilter that caches the
NtlmPasswordAuthentication Principle in a session attribute (provided
there was a non-null username in it).   It then uses the code from
Kevin's NTLMPostFilter to handle the additional IE requests and
returns the cached NtlmPasswordAuthentication as the UserPrincipal in
a RequestWrapper.

It's a drop-in replacement for NtlmHttpFilter with one additional
optional init-param parameter for specifying which session attribute
to use.

If Kevin's ok with the use of his code, is there any interest in
making this filter available?   If nothing else, I could post it to
the mailing list.


On 9/21/06, Kevin Tapperson <kevin at tapperson.net> wrote:
> Fahad,
>
> 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
> HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Internet
> 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
> application.
>
> 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:
> >
> >
> http://lists.samba.org/archive/jcifs/2004-December/004459.html
> >
> >
> >
> >
> >
> > 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?
> >
> >
> >
> > Regards,
> >
> > Fahad Siddiqui
> >
> >
>
>
>
> --
> Kevin Tapperson
> kevin at tapperson.net
> (615) 403-0817


More information about the jcifs mailing list