[jcifs] NTLMv2 and jCIFS

Mon Mar 17 16:19:24 GMT 2008

Did you manage to solve it, in case the lmCompatibilityLevel in the registry
was set below 2, and the NTLM2 Session Security was on (0x20080030) ?

On Mon, Mar 17, 2008 at 6:10 PM, Jay Kraly <jaykraly at gmail.com> wrote:

> I ended up putting in a second hack that only forces the NTLM2 flag if the
> original request comes from a browser/system capable of supporting it.  I
> now check the negotiate_128 flag, and if it is set in the original type 1
> request I force the NTLM2 flag in the type 2 challenge.  I decided on the
> 128 flag by analyzing the type 1 flags sent from various browser
> configurations with different security settings and picking the flag that
> only showed up under the highest security (questionable at best I know).  I
> can now authenticate correctly with 0x00000000 and 0x20080030, as well as
> browsers which do not have my server in their "trusted" domains (meaning
> they use a pop-up password dialog).
>
> In any case, I luckily do not have to use this in a production environment
> yet and this is working enough for my controlled group of customers so I am
> going to stop here.
>
> Good luck with your research and I will be watching the board to see if
> you find a real solution!
>
>
> On Mon, Mar 17, 2008 at 5:08 AM, Asaf Mesika <asaf.mesika at gmail.com>
> wrote:
>
> > First, thanks a lot for the information. It helped me a great deal!
> >
> > I've managed to advance my self a little further, so I'd like to
> > summarize my problematic situation.
> > Maybe someone will be able to clarify this.
> >
> > There are three types of responses from a typical Windows workstation:
> > 1. NTLMv1 token.
> > 2. NTLMv2 token.
> > 3. NTLMv1 token, encoded differently. This is called NTLM2 Session
> > Security (Session Response).
> >
> > jCIFS handles NTLMv1 and NTLMv2 out of the box.
> >
> > The problem starts with the NTLM Session Security. This can enabled in a
> > workstation, by altering the following registry key:
> >
> > HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
> >     ntlmminclientsec
> >
> > One you set the "NTLMv2 session security" flag on, in this registry key,
> > you get the following problems:
> >
> > 1. Internet Explorer refuses to respond to the type-2 message sent by
> > jCIFS.
> >
> >         The reason: the flag "Negotiate: NTLM2 Key" is not true, in the
> > type-2 message flags.
> >
> >         The semi-working bypass: Always turn-on that flag in the type-2
> > message we're returning.
> >         This causes IE to respond with a type-3 message.
> >
> >          Semi working, because:
> >          a) Workstations *without* "NTLMv2 session security" flag on (in
> > the registry) on, will fail authentication in the DC level (SMB Exception:
> > Bad User name of password).
> >
> >                 WHY?    Someone might have a clue?
> >
> >           b) The value of "NTLMv2 session security" flag (in the
> > registry) is not passing, in any form, in the NTLMSSP negotiation (with
> > jCIFS).
> >               An naive approach might think that the "Negotiate: NTLM2
> > Key" in the type-1 message (Internet Explorer is passing) will be equal to
> > the "NTLMv2 session security" flag (in the registry) , but *it is not*.
> >
> >           This brings me always to the conclusion, that only the
> > following will work:
> >             1. All organization workstations must have the same NTLM
> > security configuration.
> >             2. If the "NTLMv2 session security" flag is on, they *must*
> > send NTLMv2 token (i.e. lmCompatibilityLevel registry key must be set to
> > 4 or 5), and I must install a patched version of jCIFS, which turns the
> > "Negotiate: NTLM2 Key" in type-2 message.
> >
> >
> > Implementing NTLM2 Session Security
> >      I started thinking of implementing the missing piece in jCIFS, but
> > I wasn't sure what the DC was expecting in this case? an NTLMv1 token? If
> > so, how can I extract it? According to the algorithm, its only one way
> > encryption (Because they use DES with a key that I don't have - NTLM
> > password hash)
> >
> >
> > Thank you,
> >
> > Asaf Mesika
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Mar 17, 2008 at 5:23 AM, Jay Kraly <jaykraly at gmail.com> wrote:
> >
> > > To clarify my configuration, I was also not able to leave my registry
> > > setting at 0x20000030 because of security policy.  I tested it out on my
> > > computer prior to implementing the hack to set the NTLMSSP_NEGOTIATE_NTLM2
> > > flag to true.  Once I confirmed that the registry setting fixed the problem,
> > > I put it back to 0x20080030 and lmCompatibility to 4.  Then I tried the hack
> > > and found that it "fixed" the problem and allowed IE to authenticate.  So
> > > there must be something else server side on your end that is still blocking
> > > the password.
> > >
> > > The other avenue I have been testing is a commercial jcifs extension
> > > from Oakland Software that claims to support NTLMv2 authentication.
> > > However, I found that authentication did not get any further than the
> > > vanilla jcifs.  Their support people told me that if the domain controller
> > > has SMB signing enabled their product (and jcifs) will not work.  You may
> > > want to check for that setting on the servers.
> > >
> > > -J
> > >
> > >
> > > On Sun, Mar 16, 2008 at 5:59 AM, AsafM <asaf.mesika at gmail.com> wrote:
> > >
> > > > I've been experiencing some difficulties with point no. 3. I have a
> > > > JBoss with the jCIFS filter installed. (version 1.2.18). Scenerio 1:
> > > > working 1. NtlmMinClientSec and NtlmMinServerSec are both set to 0x0. 2.
> > > > jCIFS lmCompatibility is set to 0. Everything is working out fine. Scenrio
> > > > 2: Not working (typical desktop in a customer organization) 1.
> > > > NtlmMinClientSec and NtlmMinServerSec are both set to 0x20080030. 2. jCIFS
> > > > lmCompatibility is set to 0. IE doens't send type-3 message. I've managed to
> > > > bypass that, by modifying the type-2 message jCIFS is sending (setting the
> > > > NTLMSSP_NEGOTIATE_NTLM2 flag to true). The returned type-3 message has both
> > > > LM and NTLM hash at length of 24, indicating a NTLM v1 response. Still, from
> > > > some reason, the authentication fails at the DC level (
> > > > jcifs.smb.SmbAuthException: Logon failure: unknown user name or bad
> > > > password.) How can this be solved, since it is obvious that the client is
> > > > sending a normal NTLM response. Thanks, Asaf Mesika
> > > >
> > > > Eric Glass wrote:
> > > >  There are some specific scenarios where LMv2 will not work
> > > > properly; from what I remember: 1) signing will not work if authentication
> > > > is done with a given account to a host in a different domain (i.e.
> > > > user is "DOMAINA\user" and computer is in DOMAINB). 2) There are issues if
> > > > you are authenticating against a server that is configured with the
> > > > "nolmhash" registry key (it apparently will not pass the LM response through
> > > > properly, even though the LM hash is technically not used in the LMv2
> > > > response). 3) There can be issues related to the
> > > > NtlmMinClientSec/NtlmMinServerSec registry settings (not necessarily limited
> > > > to LMv2). I had done some related work that I keep meaning to backport in to
> > > > jCIFS; as Vista apparently uses NTLMv2/LMv2 by default this may become a
> > > > more common issue anyway. In the meantime, if the server/DC requires
> > > > LMCompatibility >= 3 and jCIFS isn't working you might need to give the
> > > > specific error messages etc. to diagnose. Eric On 12/6/06, Adis Katkic
> > > > wrote: > > Hi > > I have a problem with jCIFS and NTLMv2. > I was reading on
> > > > many places on the Internet about this but I'm still not > sure if I should
> > > > give up. > What I come up to is: > > 1. jCIFS can handle LMv2 which is some
> > > > kind if NTLMv2 but diffirent length > of blob or somthing like that. > > 2.
> > > > This means that jCIFS may be used with NTLMv2 if server uses Pass Trough >
> > > > Authenication? > Am I right here? > > 3. lmCompability for NtlmHttpFilter
> > > > must be set to 3. > > However I tried to make it work but it just wouldn't
> > > > work. I'm not sure if > my AD uses Pass trough authentication but I suspect
> > > > it doesn't. > I can log in from different domain than server domain and if I
> > > > understood > well it does not work with Pass trough. > > Any ides how to
> > > > proceed? Is there some other component out there that could > help me? > I
> > > > found code that Konstantin Kasatkin wrote but I don't know how to use it. >
> > > > How about JNDI, is there some components that use JNDI to login via Active >
> > > > Directory. > In my opinion documetation about this issue is quite little. >
> > > > > I'm thankfull for any kind of help. > Adis Katkic >
> > > > ________________________________ > Express yourself instantly with MSN
> > > > Messenger! MSN Messenger Download today > it's FREE!
> > > >
> > > >
> > > > ------------------------------
> > > > View this message in context: Re: NTLMv2 and jCIFS<http://www.nabble.com/NTLMv2-and-jCIFS-tp7720803p16077710.html>
> > > > Sent from the Samba - jcifs mailing list archive<http://www.nabble.com/Samba---jcifs-f13153.html>at
> > > > Nabble.com.
> > > >
> > >
> > >
> >
>
-------------- next part --------------
HTML attachment scrubbed and removed