We are now in the process, several years late, of trying to disallow use LM and NTLM authentication on our campus. First attempt? Train Wreck!
For stage 1 of enforcement we chose to restrict our domain controllers to accept only NTLMv2 authentication, and reject LM/NTLM. Our thinking was that clients are supposed to negotiage for the the best auth security available, so by forcing NTLMv2 at the DC, we would be able to quickly flush out non-compliant clients. Futher, we assumed that there would not be a lot of non-compliant clients. Guess what? We were WRONG WRONG WRONG
You know which clients are non-compliant? Windows 7, IE8, IE8, FireFox 4b10, Chrome 9. What? Really? It’s true… when accessing IIS web servers configured to use Windows authentication, with NTLMv2 enforced on the authenticating server, even Windows 7 will negotiate down to the weakest possible NTLM level. So… access to SharePoint 2007 from IE 9 beta on Win 7 falls back to welcome-to-the-80s LM authentication. This is very shocking, and annoying. When inspecting authentication negotiation traffic to the web server, we see that both client and server have indicated that NTLMv2 is supported, and that LM should not be used. However, when the client sends its authentication challenge response, it sends NTLM and LM responses only and not NTLMv2. Only by setting local security policy on the Windows client to “NTLMv2 only” are we able to prevent the sending of LM/NTLM. Negotiation is a lie!
So, we are going to take this us with MS Support. Some resources that may be helpful going forward:
A good explanation of how the “LMCompatibilityLevel” security setting works. Contains one major factual error… it claims that clients and servers will always negotiate the highest mutually-support LM auth level. This may be true for SMB/CIFS. It certainly is not true for web auth.
Over at Indiana University, LM/NTLM has been disabled for some time. They have thorough documentation on configuring workstations to function properly in their more restrictive environment. This page concerns the use of SharePoint at IU, and the required configuration settings for various browsers and operating systems for their network. There is nothing specific to our problem here, but there is the implication that they experienced problems similar to our own. All of their docs state that you must configure your client to perform NTLMv2 only, or authentication will fail. Also included are notes on FireFox and Mac platforms, where client-side configuration apparently is required.
An additional page that suggests that network clients will not be able to authenticate to IU resources unless they disabled NTLMv2 on the client.
Concerning FireFox on Windows:
A developer notes that as of FF 3.6, FF uses Microsoft APIs for NTLM authentication. So, if FF is not performing NTLM auth as you expect, you need to look to your OS for the source of the problem. It’s true… we confirmed via packet capture that FF 4.0b10 and IE9RC both perform NTLM authentication in exactly the same way.
Concerning Macintosh client settings:
Recommended smb.conf file settings to enforce use of NTLMv2 on the Mac. References are made here to an “nsmb.conf” file, which is not a typographic error. More on this file here: