illumos gate

Add info from original author that he posted on jcifs@lits.samba.org

X CIMO
2013-04-07 18:42:57 GMT

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 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.

Anyone is willing to help on investigating that one?

Is there a chance that this issue will be looked at?

The issue is still open as of OmniOS r151012 http://omnios.omniti.com/wiki.php/ReleaseNotes/r151012

This is cutting out basically all the Android apps from illumos server. The only app I found able to somehow get past it is File Explorer HD, that at the second attempt (exactly at the second, never at the fist one) gets accepted.

Accessing SMB share with user/password works for me (using BSPlayer here), however the guest access does not work.

Interesting.

I just downloaded the latest OmniOS release, installed it in a VBox VM, created some smb shares with standard settings ("zfs set sharesmb=on dataset"), created a user, added the line in pam.conf ("other password required pam_smb_passwd.so.1 nowarn"), changed password for the user to regenerate the smb hash, then started File Explorer HD under Android 5.0.2 and verified once again that at the first attempt the connection gets refused with "wrong password" and at the second attempt I got in.

If your setup works, what is your setup? I also tried BSPlayer that, as any other Android app I tested, does "pure" (so to say) retries, therefore (in both my setups) never gets to the second attempt, while File Explorer somehow by retrying once gets in.

My OmniOS VM is 2.6 GB, I can also upload it somewhere so that you can try yourself and maybe understand what's going on, since I don't know network stuff as in depth as the original poster here, that was able to capture the packets.