Disable "ntlm auth" by default

[Andrew Bartlett]

On Sat, 2016-07-23 at 00:00 +0300, Uri Simchoni wrote:
> 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.

We have lots of time to tweak the WHATSNEW with more affected software,
but for now the original patch and the suggestions so far are:

Reviewed-by: Andrew Bartlett <abartlet at samba.org>

I would like to see this in master, and we can sort out further docs
during the RC period.

(NTLMv1 is entirely insecure from even a passive eavesdropper at this
point).

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba