[jcifs] NTLMv2 support

[Laud, Amar]

Eric,

Thanks for your reply. It helped me understand the issue better. One
question related to LMv2 and pass through authentication. You mentioned that
LMv2 without NTLMv2 might work only in pass through authentication. We use
jCIFS to validate a user credentials against a domain server. It seems that
we won't be doing pass through authentication in such a scenario. So, we may
see issues authenticating users in such cases ?

Thanks.

Amar

Note : Chris, thanks for the reference link on the LMv2 and NTLMv2
difference.


-----Original Message-----
From: Eric [mailto:eglass1 at comcast.net]
Sent: Thursday, September 25, 2003 5:01 PM
To: Laud, Amar
Cc: 'jcifs at lists.samba.org'
Subject: Re: [jcifs] NTLMv2 support



> I am new to the jcifs and have a question regarding supporting NTLMv2. The
> latest API documentation mentions about jcifs.smb.lmCompatibility property
> which allows LMv2 response. I also stumbled on one of the archived
messages
> which talked about LMv2 being effectively same as NTLMv2. Does anybody
know
> the latest plans on supporting NTLMv2 in jcifs ? Is LMv2 response enough
to
> work with Windows 2003 domain server configured to use NTLMv2?
> Thanks.
> Amar
> 

jCIFS just sends the LMv2 response, rather than both the LMv2 and 
NTLMv2; this should authenticate properly in *most* cases.

Cryptographically, the LMv2 and NTLMv2 responses are more or less 
identical; there are, however, some semantics attached to the NTLMv2 
TargetInformation structure that are difficult to reconstruct without 
CIFS extended security.

Basically, the TargetInformation structure is sent in the NTLM type 2 
message along with the challenge; this is normally copied verbatim into 
the type 3 NTLMv2 response.  Under extended security, you get a full 
NTLM type 2 message, so you can do this properly.

With jCIFS, we don't do extended security currently; we just get a 
challenge, and would have to "fake" an appropriate TargetInformation 
structure.  In many scenarios, the TargetInformation isn't checked, so 
doing NTLMv2 this way works properly.  I had difficulties, however, when 
authenticating a user in Domain A against a machine whose primary domain 
was Domain B.

Sending only the LMv2 response seems to alleviate most of these issues. 
  I have seen some issues authenticating against standalone servers and 
with local accounts; it may be that LMv2 without NTLMv2 only works in a 
passthrough scenario.  More research is probably warranted.  But in most 
cases, it works fine.  This is probably a roundabout way of answering 
your question ;)


Eric