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

[Michael B Allen]

On Thu, 17 Mar 2005 13:24:08 -0500
Richard Caper <rcaper at gmail.com> wrote:

> > > 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.

I'm not sure about the precise scenario under which jCIFS will fail in
a strictly non-NTLMv1 environment. I do not recall any negitive reports
but I'm also not going to proclaim it fully supports NTLMv2.

> > 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.

Good point. I'll keep this in mind but I thik the "no trusted third
party" scenario is limited to certain domain administrative functions like
establishing trusts, replication, and so on so still I don't think NTLMv2
is a high priority. Also I think we would need to implement NETLOGON w/
SecureChannel to cover the "no trusted third party" scenario so the
return on investment isn't compelling.

> > 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.

A separate Filter could still call on jCIFS as an external library to
handle NTLM authentication. I'm just saying because everyone is rapidly
moving to Kerberos it makes less sense to ship it with jCIFS. It should
be shipped and supported separately and only call upon jCIFS as necessary
to support the occasional NTLM client (just like Wedgetail).

Mike

-- 
IRC - where men are men, women are men, and the boys are FBI agents.