[jcifs] NTLMv2 and jCIFS

Mon Mar 17 17:23:16 GMT 2008

No, mine fails with the same error you get when lmCompatibility is set to 0
on the client.  And now I have locked myself out of the system for too many
failed login attempts :)

On Mon, Mar 17, 2008 at 12:19 PM, Asaf Mesika <asaf.mesika at gmail.com> wrote:

> Oops, I ment below 4.
>
>
>
> On Mon, Mar 17, 2008 at 6:19 PM, Asaf Mesika <asaf.mesika at gmail.com>
> wrote:
>
> > 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