Project

General

Profile

Bug #3594

Accessing a password protected CIFS share from an android device always fail

Added by x-cimo x almost 7 years ago. Updated over 4 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2013-02-24
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

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.

History

#1

Updated by fred bourqui over 6 years ago

Add info from original author that he posted on

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.

#2

Updated by x-cimo x over 6 years ago

Anyone is willing to help on investigating that one?

#3

Updated by Anarion Dunedain over 5 years ago

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

#4

Updated by Olaf Marzocchi over 4 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.

#5

Updated by Yuri Pankov over 4 years ago

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

#6

Updated by Olaf Marzocchi over 4 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.

Also available in: Atom PDF