[jcifs] JCIFS issue authenticating with Solaris (OmniOS/OpenIndiana/Illumos)

[X CIMO]

I have seen multiple instance of users authenticating from an Android
device to a Solaris based NAS with ZFS file system. I have reproduced the
issue myself with OpenIndiana and OmniOS (both open source), the latest
version of Oracle Solaris 11.1 dosen't suffer from the same problem.

I have spent some time looking into it and found out that most (if not all)
android app with SMB support use JCIFS. I also found one android app: Total
Commander, had a work around for older NAS that made it work with my OI NAS.

This workaround is:

jcifs.Config.setProperty("jcifs.smb.client.useExtendedSecurity", false);
jcifs.Config.setProperty("jcifs.smb.lmCompatibility", 0);

0,1 -- Sends LM and NTLM responses.
2 -- Sends only the NTLM response. This is more secure than Levels 0 and 1,
because it eliminates the cryptographically-weak LM response.
3,4,5 -- Sends LMv2 and NTLMv2 data. NTLMv2 session security is also
negotiated if the server supports it. This is the default behavior (in
1.3.0 or later).

So it seems fair to assume that most today's would use LMv2/NTLMv2.


On the Solaris side now, both OI and OmniOS are distribution based on
illumos (http://wiki.illumos.org).

>From the manual I found the following:

lmauth_level

         Specifies the LAN Manager (LM) authentication level. The  LM
compatibility level controls the type of user authentication to use in
workgroup mode or  domain  mode.  The default value is 4.

         The following describes the behavior at each level.

         2           In Windows workgroup mode, the Solaris CIFS server
accepts  LM, NTLM, LMv2, and NTLMv2 requests. In domain mode, the SMB
redirector  on  the Solaris CIFS server sends NTLM requests.

         3            In Windows workgroup mode, the Solaris CIFS server
accepts  LM, NTLM, LMv2, and NTLMv2 requests. In domain mode, the SMB
redirector  on  the Solaris CIFS server sends LMv2 and NTLMv2 requests.

         4           In Windows workgroup mode, the Solaris CIFS server
accepts  NTLM,  LMv2,  and  NTLMv2 requests. In domain mode, the SMB
redirector  on  the Solaris CIFS server sends LMv2 and NTLMv2 requests.

         5           In Windows workgroup mode, the Solaris CIFS  server
accepts LMv2 and NTLMv2 requests. In domain mode,  the  SMB  redirector
on  the Solaris  CIFS  server sends LMv2 and NTLMv2 requests.

What am I seeing:

>From an app perspective the issue is that the password is refused (Bad
password).
I then fired up wireshark and put myself in between my NAS and my Nexus7
tablet.
>From a network perspective here is what is happening:

Bit of background info: In wireshark and SMBv1:
LM hash is named: ANSI Password, (CaseInsensitive hash)
NT hash is named Unicode Password. (CaseSensitive hash)

On a standard Android APP (using JCIFS) here is what I see:
NT Create AndX Response contain the ANSI Password:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (24 bytes length)
This FAIL.

On total commander in "compatiblity" mode I see:
NT Create AndX Response contain the
ANSI Password: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX (24 bytes length)
Unicode Password: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY (24 bytes length)
This WORKS

In addition my Windows 8 machine use the following:
NT Create AndX Response contain the
ANSI Password: 000000000000000000000000000000 (24 bytes NULLs)
Unicode Password: YYYYYYYYYYYYYYYYYYYYYYYYYYYYYY (24 bytes length)
This WORKS

For reason I don't understand it seem that by default when JCIFS
authenticate with my NAS, it sends only the LM(v2?) Hash.

When I use total commander compatiblity it sends the LM + NTLM hash, and
that works.

Where I gets confused is that OI/OmniOS/Illumos fully support
LM/LMv2/NTLM/NTLMv2.

I have tried to lower the lmauth_level on illumos so it allow LM hash but
without success. (Still fail).

Anyone has an idea why JCIFS would send just a ANSI Password (LM hash) by
default?, and more importantly why it would fail?

I will also try to find idea on the Illumos mailing list.

Thanks everyone.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.samba.org/pipermail/jcifs/attachments/20130407/1dc2a940/attachment.html>