Disable "ntlm auth" by default

[Uri Simchoni]

On 07/22/2016 02:09 PM, Stefan Metzmacher wrote:
> Am 22.07.2016 um 12:11 schrieb Matthew Newton:
>> Hi,
>>
>> On Fri, Jul 22, 2016 at 11:36:09AM +0200, Stefan Metzmacher wrote:
>>> Am 22.07.2016 um 11:17 schrieb Andrew Bartlett:
>>>> On Fri, 2016-07-22 at 10:15 +0200, Stefan Metzmacher wrote:
>>>>> here're patches which change the default of the "ntlm auth"
>>>>> option from yes to no.
>>>>
>>>> The primary user of NTLMv1 is MSCHAPv2 for VPNs and 802.1x.  This needs
>>>> to be called out in the docs.  Ideally we would have a tri-state here
>>>> to support this only when the MSV1_0_ALLOW_MSVCHAPV2 flag is specified
>>>> by a client. 
>>>
>>> I've added notes regarding "The primary user of NTLMv1 is MSCHAPv2 for
>>> VPNs and 802.1x".
>>
>> A view from another side...
>>
>> There are a lot of people using FreeRADIUS and Samba to
>> authenticate (mostly wireless) connections with 802.1X, and it
>> comes up on the FR lists quite a lot.
>>
>> Disabling NTLMv1 is a good thing, but I'm sure it would be
>> appreciated if the notices informing people of this were as clear
>> as possible, to save more questions on the list of "why did
>> FreeRADIUS break when I upgraded Samba" :-)
>>
>> The above is good, but I'm not sure whether people would
>> associate it quickly with "upgrading to this Samba will break my
>> wireless authentication".
>>
>> Is this alternative too long-winded?
>>
>>   The primary use of NTLMv1 is MSCHAPv2 for VPNs and 802.1X. For
>>   example, PEAP/MSCHAPv2 for wireless network or VPN authentication
>>   with RADIUS will need this option enabled.
> 
> Thanks! added.
> 
> metze
> 

Another use of NTLMv1 is by the Linux CIFS client. NTLMv1 has been the
default for some time (up until Linux 3.7 according to Jeff Layton's
2013 SambaXP presentation). Such a client using the default would fail.
The workaround is to specify sec=ntlmssp mount option.

There's also this thing with the Linux client when switching from NTLM
to NTLMSSP, where if the server is joined to a domain, and the mount
command does not specify a domain, then mounting using local credentials
would succeed for sec=ntlm and fail for sec=ntlmssp (because sec=ntlm
sends an empty domain and sec=ntlmssp sends the peer's domain, which
sends the server looking for the user in AD). Not sure this is
fundamental to NTLMSSP vs NTLM or a cifs.ko quirk, but a user whose
setup broke and is now trying to add sec=ntlmssp may stumble upon this
one too.

Thanks,
Uri.