Archive

—DISCLAIMER—
This is a rapid publishing post and may not include all necessary links and references and is not likely to meet the quality standard you and I expect of my blog posts.

SCENARIO:
A client company had a network and systems vulnerability testing done and were asked to disable storage of LANMAN hashes and LANMAN authentication to pass the audit.

I expect the audience of this article to have a basic understanding of authentication in Windows based networks and familiarity with the words LANMAN, NTLM and Kerberos is expected. There is plenty of information available online covering why LANMAN is bad so I’ll not duplicate that and get straight to the process to follow to disable the use of LM.

SOLUTION:
There are two parts to the solution.

Disabling the storage of LM Hashes

Create a group policy object “NoLmHash” or call it whatever your preference or naming convention dictates.

Enable the setting “Network Security: Do not store LAN Manager has value on next password change.”

The above will not clean up any previously stored LM hash values and only means Windows will not compute and store new LM hash values for new passwords. You may also want to note that this setting is already included in the Default Domain Policy in a new Windows Server 2008 R2 domain. Also, Windows Vista and Windows 7 (also Windows Server 2008 and Windows Server 2008 R2) have LM hashes disabled by default and can be confirmed by navigating to registry value “NoLmHash” under HKLM\System\CurrentControlSet\Lsa.

Disabling LM Authentication

Create a group policy object “NoLmAuthClient” as below and assign it to all computers except DCs.

Enable the setting “Network Security: LAN Manager Authentication Level” and set it to “Send NTLM response only”. Microsoft explanation for this setting, self explanatory as it is, is “Clients use NTLM authentication only and use NLTMv2 session security if the server supports it; domain controllers accept LM, NTLM and NTLMv2 authentication.”

To add further clarity, the above will prevent all clients from using LM, but DCs will continue to accept LM.

To stop the DCs from accepting LM, create a group policy object “NoLmAuthDC” as below and assign it to all domain controllers.

Enable the setting “Network Security: LAN Manager Authentication Level” and set it to “Send NTLMv2 response only\refuse LM”. Microsoft explanation for this setting is “Clients use NTLMv2 authentication only and use NTLMv2 session security if the server supports it; domain controllers refuse LM (accept only NTLM and NTLMv2 authentication).”

The above will prevent the DCs from accepting LM. There’s more to play with in the same GPO area and you can configure LM auditing. I’ll leave it to your brilliant minds and capable hands; it shouldn’t be very hard from here on.

You can also go a step further and disable NTLM as well and allow just NTLMv2. It’s different values of the same setting “Network Security: LAN Manager Authentication Level”. You’ll get on just fine but send any questions in comments if needed.

RISKS/CAVEATS

These settings may cause and an issue where you have Windows NT4.0 or older clients on your network. But since very old versions of Windows are not held on to with much love for years, I wouldn’t worry too much about it, not for networks I manage.

OTHER USEFUL INFORMATION

Windows 95 and Windows 98 do not support NTLM.

Windows NT 4.0 earlier than SP4 does not support NTLMv2 and all Windows versions since Windows NT 4.0 SP4 support NTLMv2.

LM is disabled by default in Windows Vista and Windows 7.

LM uses LM hash which is the least secure way of storing a password in Windows.

NTLM credentials consist of a domain name, a username and a one-way hash of the user’s password.

NTLM does not support AES or SHA-256. It uses CRC for integrity and RC24 for encryption.

NTLM uses an encrypted challenge/response protocol and does not send the password over the wire.