[jcifs] RE: FW: ntlm_auth integrated with Tomcat5 filter

Richard Caper rcaper at gmail.com
Thu Mar 17 18:24:08 GMT 2005


> > We're anticipating the need to authenticate Tomcat5 session against
> > "NTLMv2 or better" domains.
> >
> > If I've mis-read or mis-interpreted the current capabilities of
> > jcifs.http.NtlmHttpFilter, please forgive me.
> 
> You are correct. JCIFS currently does not support NTLMv2 or Kerberos. 


Is there a particular scenario where jCIFS does not work in such an
environment?  Our network is set up with LMCompatibilityLevel = 5, and
setting the jCIFS property matching seems to work fine.  I don't know
how the servers can be configured to "block" LMv2 in the same way it
can LM/NTLM.  The browser sends the LMv2 and NTLMv2 responses, but
jCIFS just forwards the LMv2 one on to the CIFS server.


> 
> Incedentally jCIFS will also very likely never support NTLMv2 because it
> is obsoleted by Kerberos. I am currently working on SPNEGO


There are some scenarios where NTLM is still used (i.e. it is not
totally replaced by Kerberos).  Machine local accounts are one, as
well as between forests.  As Kerberos is a trusted-third-party
protocol, it can't be used when there is no trusted third party.  NTLM
is used as it is challenge/response and not necessarily based on a
central password store.


> jCIFS 2.0. However, after doing so I'm not certain about the future of an
> HTTP Filter in jCIFS moving forward because a Kerberos only filter by
> itself really has nothing to do with CIFS. For this reason it would be
> nice if someone could create a nice standalone Kerberos filter with a
> clean way for sub-filters to access the negotiated ticket (e.g.

But there is no standalone Kerberos web authentication; just NTLM and
Negotiate (which can be either NTLM or Kerberos depending on what the
browser supports and chooses).  Kerberos-only would "block out" any
browsers that do not support (older ones like Windows 98), and also
prevent it from authenticating with a local account.  Wedgetail I
believe actually falls back to using NTLM with jCIFS in this scenario.


More information about the jcifs mailing list