I have a Windows 7 client (in domain) and a modern Samba server on Archlinux on a VM. And we also have other really old samba servers in our intranet. I set `LmCompatibilityLevel=1` to be able to connect to those old servers. After a recent update to Samba 4.5.2 I was unable to connect to my share: > net use \\192.168.56.3\il 123 /user:x\il System error 86 has occurred. The specified network password is not correct. and the samba client log contains the words: ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user Looks like I was using NTLMv1 the whole time: before "4.5.2" the config parameter "ntlm auth" was "yes" by default. Now it's "no". I found two workarounds that worked: - Turning it back to "yes" in my smb.conf. - setting LmCompatibilityLevel=3 and restarting the NetLogon windows service. The 1st workaround makes it insecure, I guess, and the 2nd one makes it impossible to use the old samba servers I mentioned. Technet says about LmCompatibilityLevel=1: > Clients use LM and NTLM authentication, and they use NTLMv2 session security if the server supports it. Is it a lie? If not, then why there's no attempt to use NTLMv2? I think it's a samba bug and it's easy to reproduce it.
Created attachment 12774 [details] my smb.conf
(In reply to Ilya Basin from comment #0) As far as I know "NTLMv2 session security" is not the same as NTLMv2 authentication. Using NTLMv1 with "NTLMv2 session security" just means that the resulting session key is constructed differently, but the client still provides the NTLMv1 response. I'm sorry but there's nothing we can do if windows doesn't allow different settings per server/connection.
Do you mean that when a windows client with LmCompatibilityLevel=1 connects to a windows server, it's insecure?
(In reply to Ilya Basin from comment #3) Yes, it's the same.