[jcifs] NTLM authentication

Kevin Tapperson kevin at tapperson.net
Mon Sep 25 20:35:13 GMT 2006


Mike, I would be fine with including my posted code in the jcifs package.
Feel free to use it, modify it, re-package it as appropriate.

On 9/21/06, Mike Kienenberger <mkienenb at gmail.com> wrote:
>
> 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
>



-- 
Kevin Tapperson
kevin at tapperson.net
(615) 403-0817
-------------- next part --------------
HTML attachment scrubbed and removed


More information about the jcifs mailing list