Disable "ntlm auth" by default

[Stefan Metzmacher]

Hi,

here're patches which change the default of the "ntlm auth"
option from yes to no.

Please review and push:-)

Thanks!
metze

[Andrew Bartlett]

Post by Stefan Metzmacher
Hi,
here're patches which change the default of the "ntlm auth"
option from yes to no.
Please review and push:-)

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 hate this flag on principle, because it perpetuates the use of
NTLMv1 rather than forcing MS to rev to a sane, secure VPN and 802.1x
protocol).

Otherwise, I'm fine with this.

Andrew Bartlett

[Stefan Metzmacher]

Post by Andrew Bartlett

Post by Stefan Metzmacher
Hi,
here're patches which change the default of the "ntlm auth"
option from yes to no.
Please review and push:-)

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".

But I think magic regarding the MSV1_0_ALLOW_MSVCHAPV2 flag, is a task
for another day.

Is the attached version fine for master/4.5 now?

metze

[Andrew Bartlett]

Post by Stefan Metzmacher

Post by Andrew Bartlett

Post by Stefan Metzmacher
Hi,
here're patches which change the default of the "ntlm auth"
option from yes to no.
Please review and push:-)

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".
But I think magic regarding the MSV1_0_ALLOW_MSVCHAPV2 flag, is a task
for another day.

Agreed. It would need good tests etc, more than we can do for now, and
this is easy to spot and fix on upgrade.

Post by Stefan Metzmacher
Is the attached version fine for master/4.5 now?

Reviewed-by: Andrew Bartlett <***@samba.org>

Thanks!

Andrew Bartlett

[Matthew Newton]

Hi,

Post by Stefan Metzmacher

Post by Andrew Bartlett

Post by Stefan Metzmacher
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.

Though there is always the general problem of people not reading
the documentation :(

FreeRADIUS as a MSCHAP client has at least got support for the
nasty MSV1_0_ALLOW_MSVCHAPV2 hack now, so things would be fine
if that makes it in to Samba.

Cheers!

Matthew

[Stefan Metzmacher]

Post by Matthew Newton
Hi,

Post by Stefan Metzmacher

Post by Andrew Bartlett

Post by Stefan Metzmacher
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

[Uri Simchoni]

Post by Stefan Metzmacher

Post by Matthew Newton
Hi,

Post by Stefan Metzmacher

Post by Andrew Bartlett

Post by Stefan Metzmacher
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.

[Andrew Bartlett]

Post by Uri Simchoni

Post by Stefan Metzmacher

Post by Matthew Newton
Hi,

Post by Stefan Metzmacher

Post by Andrew Bartlett

Post by Stefan Metzmacher
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 <***@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

[Uri Simchoni]

Post by Stefan Metzmacher
Hi,
here're patches which change the default of the "ntlm auth"
option from yes to no.
Please review and push:-)
Thanks!
metze

Does Windows have such a mode that would accept only NTLMv2-SSP? (the
combination of disabling ntlm auth and raw ntlmv2) They don't seem to
make the distinction between "raw" and SSP in their docs...

Thanks,

Uri

[Stefan Metzmacher]

Post by Uri Simchoni

Post by Stefan Metzmacher
Hi,
here're patches which change the default of the "ntlm auth"
option from yes to no.
Please review and push:-)
Thanks!
metze

Does Windows have such a mode that would accept only NTLMv2-SSP? (the
combination of disabling ntlm auth and raw ntlmv2) They don't seem to
make the distinction between "raw" and SSP in their docs...

I don't know about the options.

But raw ntlmv2 is completely disabled for quite some time without an option.

metze

[Uri Simchoni]

Post by Stefan Metzmacher

Post by Uri Simchoni

Post by Stefan Metzmacher
Hi,
here're patches which change the default of the "ntlm auth"
option from yes to no.
Please review and push:-)
Thanks!
metze

Does Windows have such a mode that would accept only NTLMv2-SSP? (the
combination of disabling ntlm auth and raw ntlmv2) They don't seem to
make the distinction between "raw" and SSP in their docs...

I don't know about the options.
But raw ntlmv2 is completely disabled for quite some time without an option.
metze

There's LMCompatibilityLevel under
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa (also settable
via group policy and whatnot). Setting it to 5 should cause the server
to refuse NTLM but in my testing, one machine (Win7) accepted NTLM and
with another (2012R2) the setting gets reset across reboot.

Strange..

Uri.