Bug #3594
openAccessing a password protected CIFS share from an android device always fail
0%
Description
There are many Android app that support SMB, however none on theses work with either OI or OmniOS.
They work fine if connecting to a Win8 fileshare, or even Solaris 11.1.
However the user/password always fail for illumos.
Updated by fred bourqui about 9 years ago
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.
Updated by x-cimo x almost 9 years ago
Anyone is willing to help on investigating that one?
Updated by Anarion Dunedain about 8 years ago
Is there a chance that this issue will be looked at?
Updated by Olaf Marzocchi about 7 years ago
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.
Updated by Yuri Pankov about 7 years ago
Accessing SMB share with user/password works for me (using BSPlayer here), however the guest access does not work.
Updated by Olaf Marzocchi about 7 years ago
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.
Updated by Gordon Ross about 1 year ago
- Category set to cifs - CIFS server and client