I found that there is no way to completely disable NTLM and NTLM V2 in samba4.
My purpose is to ensure if someone bring their own workstations back to office and they cannot connect to samba4 server using their username and password.
On Windows, there are a Security Settings to do this (Local Policies ->Security Options -> Network Security: Restrict NTLM: Incoming NTLM Traffic)
I have confirm with Jeremy Allison that such configuration is not available at the moment.
So, May I request Samba development team to add such feature in the future ? This is a very important security feature. Please consider.
This is planed for 4.5 or 4.6 in a similar way to windows
Completely untested, but "gensec:ntlmssp=no" together with "ntlm auth = no" in the [global] section of smb.conf may already provide something...
We might want to imply gensec:ntlmssp=no if ntlm auth = no is set.
I'll investigate !
(In reply to Jeremy Allison from comment #3)
No, "ntlm auth" just means NTLMv1 is disabled and we'll disable that by default
for 4.5. I've already started with the patches.
We really need "server ntlm blocked", "client ntlm blocked" or "client ntlm whitelist" options and implement them like the options on windows.
Well people use "ntlm" as a generic catchall term for both v1 and v2. Maybe we need separate "ntlmv1" and "ntlmv2" patramters with "ntlmv1 = no" by default, and a generic "ntlm = no" disables both.
That seems logical to me, but I'm not wedded to the idea.
(In reply to Jeremy Allison from comment #5)
"ntlm auth" already exist (with a default of "yes") together with
"lanman auth" (with a default of "no").
Oh. That's horribly confusing :-). I don't think Microsoft use "lanman auth" anymore in their docs.
(In reply to Jeremy Allison from comment #7)
I do agree. I wish I had chosen better names when I was adding them a long time ago.
A useful way forward would be:
ntlm auth = [ yes | no / ntlmv2-only | mschapv2-and-ntlmv2-only | disabled ]
Disabled should kill both the SAMR password change (RC4 based) and the NTLM auth stack.
The alias of no -> ntlmv2-only is unfortunate, but is the best way out of this pickle.
(In reply to Andrew Bartlett from comment #9)
I think on Windows it's possible to do the restriction per something like
E.g. for "require strong key = yes" we allow
"require strong key:NETBIOSDOMAIN = no" to overwrite it.
I think we also need to separate between the 3 cases:
- restrict the client side to never use NTLM*
- restrict in the server code (the smb server for non spnego dialects
and the NTLMSSP server)
- restrict NTLM* in the netlogon server, based on computer name
and domain name, maybe also user name.
But "ntlm auth = [ yes | no / ntlmv2-only | mschapv2-and-ntlmv2-only | disabled ]" is certainly a got start. I'm just not sure how to do overwrites.
"ntlm auth:domain $DOMAIN = [ yes | no / ntlmv2-only | mschapv2-and-ntlmv2-only | disabled ]"
"ntlm auth:computer $COMPUTER = [ yes | no / ntlmv2-only | mschapv2-and-ntlmv2-only | disabled ]"
"ntlm auth:user $USERDOMAIN\\$USER = [ yes | no / ntlmv2-only | mschapv2-and-ntlmv2-only | disabled ]"
(In reply to Stefan Metzmacher from comment #10)
Honestly, I would prefer to have that be extensions in the directory, not smb.conf values.
We need to read up on the protected groups etc.
(In reply to Andrew Bartlett from comment #11)
Yes, it would be good to implement it like Windows,
but I fear that there's much more work required for that.
Created attachment 13418 [details]
test for this bug backported from master
The attached patch confirms that we do disable NTLM password changes when ntlm authentication is disabled against this SAM.
Karolin, please pick this for the next 4.7rc
(In reply to Stefan Metzmacher from comment #14)
Pushed to autobuild-v4-7-test.
Pushed "test for this bug backported from master" to v4-7-test.
Re-assigning to Andrew.
Closing as fixed in Samba 4.7 and later. The original issue is resolved, additional possible security features can be implemented when time permits.