[jcifs] NTLMv2 and jCIFS

Mon Mar 17 09:08:19 GMT 2008

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