Update to FreeNAS-9.10.2-U2 broke SMB permissions

[Vihren Todorov]

the freenas device does not have the directory services running.

AD Functional level is also 2012

 

[Helio Tadao Goto]

No AD in my home office, Windows 10 Pro updated until today and Linux Debian 7 using cifs and Samba client 3.6.6

 

[wanders]

Thanks for this! Same problem solved by the "ntlm auth = yes" aux params. Whew.

 

[James Newport]

Thanks for this! Same problem solved by the "ntlm auth = yes" aux params. Whew.

Can confirm "ntlm auth = yes" aux params solved this problem for me.

 

[Shawn Williams]

Thanks anodos. "ntlm auth = yes" aux params solved this problem for me too. Weird problem though. My win 7 machines had no problem. 3 win 10 machines had no problem. However my main win 10 machine that i use everyday would not connect no matter what I tried until your post. Seems maybe related to what updates are on our windows machines. just a guess i didn't compare that.

 

[anodos]

Thanks anodos. "ntlm auth = yes" aux params solved this problem for me too. Weird problem though. My win 7 machines had no problem. 3 win 10 machines had no problem. However my main win 10 machine that i use everyday would not connect no matter what I tried until your post. Seems maybe related to what updates are on our windows machines. just a guess i didn't compare that.

Do you have any 3rd party security software on the main computer? I'm wondering if some software isn't forcing downgrade to ntlmv1. Got the attention of the Russian mafia perhaps? Is one a WiFi link and others wired?

Primary reasons for NTLMv1 being required are 802.1x / MSCHAPv2.

Please note that NTLMv1 should not be used in production in a business environment. At this point there is little difference between using NTLMv1 and sending passwords in the clear. Disabling it may be required for security compliance.

 

[norbs]

Hmm same here, having SMB issues after every since I installed U2. I don't use AD just local freenas users.

Oddly enough not all machines are having the issue.

• MRMC (kodi app for apple TV) stopped being able to access it
• One of my two windows 10 PCs stopped other is fine
• Windows 2012R2 server is having no issues
• MacOS Sierra laptop is working just fine

I can't really find any correlation to the problem but "ntlm auth = yes" seemed to have fixed the issue though I didn't get to try MRMC again.

 

[Greg Thomas]

I had the same issue. I have 4 machines in my house that I use FreeNAS with. 2 are personal running Win10 and had no issues connecting after upgrading to 9.10.2-U2. The other 2 are part of my corporate domain and are running Win7. Both of those would give me the invalid password. Adding the auxiliary parameter ntlm auth = yes via the FreeNAS webui under "services" - > "SMB" fixed it for me too. I also run Plex on my FreeNAS box and none of the media clients had any issues, nor did my Android phone.

 

[nemisisak]

Thanks anados. I also had the same problem for my Raspberry pi running OSMC. All windows 7 machines are connecting to the share fine. Heres a bit of info for everyone regarding NTLM...


The following steps present an outline of NTLM noninteractive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process.

1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.
2. The client sends the user name to the server (in plaintext).
3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.
4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.
5. The server sends the following three items to the domain controller:
   • User name
   • Challenge sent to the client
   • Response received from the client
6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.
7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

This seems to have been deactivated because as with most legacy protocls it is vulnerable to attacks. In this case a pass the hash attack,

"After an attacker obtains valid user name and user password hash values, they are then able to use that information to authenticate to a remote server or service using LM or NTLM authentication without the need to brute-force the hashes to obtain the cleartext password (as it was required before this technique was published). The attack exploits an implementation weakness in the authentication protocol, where password hash remain static from session to session until the password is next changed.

This technique can be performed against any server or service accepting LM or NTLM authentication, whether it runs on a machine with Windows, Unix, or any other operating system."

The answer to NTLM authentication to Kerberos which is a new protocol that works on the basis you are connected on an open network and seeks to encrypt the traffic to avoid such attacks. From my understanding there is meant to be a fallback protocol for clients who dont have Kerberos. This must be disabled by default in freenas.

Therefore its probably a good idea to monitor this and deactivate NTLM once updates for windows/kodi etc have been pushed through.

 

[DGenerateKane]

Count me in as another user who lost Samba after upgrading. ntlm auth = yes also fixed it.

 

[Stick]

Just wanted to say that the ntlm auth = yes also worked for me. In my case, the shares were working fine from all of our windows machines, but our Toshiba copier was throwing a 2d64 authentication error whenever we tried to scan to any folder on the network drive. Spent all day pulling my hair out trying to figure out why every other machine could authenticate with FreeNAS, and the copier could authenticate with any of our other machines and also my backup FreeNAS box (which is running an older FreeNAS version).

 

[DSN]

An alternative to forcing FreeNAS (Samba) into using NTLMv1 is to allow Windows 7 (10 as well?) to negotiate more options. You can do this by removing the LmCompatibilityLevel registry key. To do this delete the regkey entry (DWORD) LmCompatibilityLevel under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\Lsa and reboot.

After deleting the key and rebooting my Windows 7 machine was able to mount the share without making any changes to FreeNAS. I didn't watch the network traffic, so I don't know if it effectively accomplishes the same NTLMv1 negotiation, but since you don't enable NTLMv1 on FreeNAS I suspect NTLMv2 is in use. If I had more time to debug I'd get a PCAP and confirm, but this is a low use home instance and I'm slightly less concerned about my wife snooping NTLM passwords than I would be an enterprise network.

Credit: https://superuser.com/questions/400...ndows-7-security-policy-option-to-not-defined

 

[MrBadAxe]

An alternative to forcing FreeNAS (Samba) into using NTLMv1 is to allow Windows 7 (10 as well?) to negotiate more options. You can do this by removing the LmCompatibilityLevel registry key. To do this delete the regkey entry (DWORD) LmCompatibilityLevel under HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Control\Lsa and reboot.

Had similar problem, followed quoted procedure, back in action. Thanks DSN for pointing this out.

 

[anodos]

Had similar problem, followed quoted procedure, back in action. Thanks DSN for pointing this out.

Out of curiosity, what level was LmCompatibilityLevel set to? By default Windows > Vista should be at a minimum of 3.

 

[pchmt]

For the sake of information, I too had my SMB share failing after the update to 9.10.2-U2. Client was a CentOS 7 VM. ntlm auth = yes fixed it for me too.

Not a complaint, but this might be useful to someone else as stupid as me and searching for a solution too ...
I spent a week trying to debug the problem as it also coincided with an update to the CentOS service ... I have learnt a lesson about staging updates ...

 

[guruNC]

I'd like to add to this that we are also seeing this. Adding ntlm auth - yes fixes the issue.

I checked our security policy and it is currently set to "Send LM & NTLM - use NTLMv2 Session Security if Negotiated" which one would think equates to if NTLMv2 is allowed, use that. However, if I configure the policy to "Send MTLMv2 response only" then everything works as expected.

We cannot leave the policy at that level because there are some ancient machines running jobs out here that we can't just cut off.

Is this all expected behavior? Or is something in FreeNAS not right?

Running Build FreeNAS-9.10.2-U3 (e1497f269) By the way. Clients are a combination, but Windows 10 and Server 2012R2 are among them.

Thanks,

 

[anodos]

I'd like to add to this that we are also seeing this. Adding ntlm auth - yes fixes the issue.

I checked our security policy and it is currently set to "Send LM & NTLM - use NTLMv2 Session Security if Negotiated" which one would think equates to if NTLMv2 is allowed, use that. However, if I configure the policy to "Send MTLMv2 response only" then everything works as expected.

We cannot leave the policy at that level because there are some ancient machines running jobs out here that we can't just cut off.

Is this all expected behavior? Or is something in FreeNAS not right?

Running Build FreeNAS-9.10.2-U3 (e1497f269) By the way. Clients are a combination, but Windows 10 and Server 2012R2 are among them.

Thanks,

The Windows options regarding NTLM are rather difficult to parse. I think it is "expected" behavior. "Send LM & NTLM - use NTLMv2 Session Security if Negotiated". This means that LM & NTLMv1 are used for authentication, then NTLMv2 can be negotiated for session security. The technet article here explains it a bit more. https://technet.microsoft.com/en-us/library/cc960646.aspx Note that (0)-(3) apply to client systems.

A little insecure yeast...

 

[guruNC]

Yes that is what I was starting to suspect after re-reading and re-reading again the policy options. Funny enough, I'm also testing on a Fedora 25 Workstation, and I'm not able to connect unless I add the following to my smb.conf

lanman auth = no
ntlm auth = yes
client NTLMv2 = yes
client lanman auth = no
client plaintext = no

But once I added that, it connects no problem.