NTLMv2

[Zachary Loafman]

In 3.0.x, NTLMv2 auth is off by default for outbound NTLM authentication
("client" connections, if you're perusing the code, which also happen to
be initiated by the samba server to talk to the DC). I'm considering
switching it to "on" by default for Isilon, but in general I feel it
should be on by default these days when running as a server. Here's the
argument:

*) We continue to run into environments that that reject NTLMv1/LM auth.
In these environments, we can't authenticate using NTLM without changing
smb.conf to force NTLMv2, which is lame. We should auto-negotiate where
possible.

*) The samba server only makes outbound NTLM connections when talking to
the DC (correct me if I'm wrong here). In particular, it gets used for
authenticated pipes to the DC, and for authentication support when
someone authenticates to the cluster (pass-thru auth).

*) Inbound NTLMv2 is supported in NT4 SP4+ and Win2K+. Basically, it's
reached the point where it's mainstream for DCs.

*) We support NTLMv2 for inbound connections anyways, so other clients
authenticating to our server aren't really affected. 

The simplistic code change I have in mind is just to flip the default,
and fix ntlmssp_client_challenge to check both the parameter and the
presence of NTLMSSP_NEGOTIATE_NTLM2 (right now, if you set the smb.conf
parameter it will always use NTLMv2, even if the packet suggests
otherwise). The better code change for people who use the client is to
create two parameters, one an "outbound server ntlmv2 auth" and
"outbound client ntlmv2 auth". I can certainly see why you'd want to
differentiate those.

Are there good reasons why the samba server can't default to NTLMv2 auth
if the negotiation says it's allowed?

--
Zach Loafman | Staff Engineer
Isilon Systems    P +1-206-315-7500    F +1-206-315-7485
www.isilon.com    D +1-206-315-7570    M +1-512-350-4291