Samba and ntlm for Windows clients

bgstack15

2017-10-01 17:06

tl;dr

Use one or the other:

1. Insecure but fast, in /etc/samba/smb.conf :

[global]
ntlm auth = yes

2. Best, on client Windows machine:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000001

Samba and ntlm

With the published "ETERNALBLUE" vulnerability (CVE-2017-0146) a few months ago, the effects finally trickled down to the default settings for samba in CentOS 7. After updating to samba 4.6.2, I was unable to access my samba share from a Windows client (using my freeipa credentials). Here's what I found in /var/log/samba/log.lsasd after setting [global] log level = 3 :

  check_ntlm_password:  Authentication for user [bgstack15] -> [bgstack15] FAILED with error NT_STATUS_WRONG_PASSWORD
[2017/10/01 16:45:54.106771,  2, pid=5289] ../auth/gensec/spnego.c:768(gensec_spnego_server_negTokenTarg)
  SPNEGO login failed: NT_STATUS_WRONG_PASSWORD
[2017/10/01 16:45:54.106860,  3, pid=5289] ../source3/smbd/smb2_server.c:3097(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../source3/smbd/smb2_sesssetup.c:134
[2017/10/01 16:45:54.107513,  3, pid=5289] ../source3/smbd/server_exit.c:246(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)
[2017/10/01 16:45:54.113588,  3, pid=5249] ../source3/lib/util_procid.c:54(pid_to_procid)
  pid_to_procid: messaging_dgm_get_unique failed: No such file or directory

After lots and lots of research, I finally found the answer at the FreeBSD forum! Gotta love the FreeBSD folks; they keep us all sane and grounded in free and open computing. Just add ntlm auth = yes to your [global] section of smb.conf! However, I looked it up and that enables samba to accept ntlmv1, which was the vulnerable protocol based on that CVE I mentioned earlier in this article. I wanted to find out how to stick to ntlmv2 authentication, if possible, and I did discover it! You can just configure your Windows clients to use the more secure settings either using the registry or the graphical secpol.msc tool. For the Local Security Policy (secpol.msc) tool, navigate to Security Settings->Local Policies->Security Options->"Network security: LAN Manager authentication level." Set it to "Send LM & NTLM - use NTLMv2 session security if negotiated."

[![secpol.msc utility showing directory tree navigated to Network security:

LAN Manager authentication level setting](/2017/10/secpol.png)](/2017/10/secpol.png) Local Security Policy window with setting

To automate this setting, you can make a registry file such as ntlmv2.reg with the following contents:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"LmCompatibilityLevel"=dword:00000001

I recognize this location from when I've adjusted it in the past, at a place that would not have been affected by this vulnerability or its remediation because they were forcing NTLMv2 years ago on the workstations.

Reference

Weblinks

Samba quick answer https://forums.freebsd.org/threads/62169/
Client secpol.msc answer https://support.symantec.com/en_US/article.TECH132917.html
Client registry answer https://kb.iu.edu/d/atcb
Notes about different values for this registry key https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-lan-manager-authentication-level

Knowledge Base