Disable LANMAN using Group Policy
—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.
- Navigate to Computer Configuration\Policies\Windows Settings\Local Policies\Security Options.
- 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.
- Navigate to Computer Configuration\Policies\Windows Settings\Local Policies\Security Options.
- 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.
- Navigate to Computer Configuration\Policies\Windows Settings\Local Policies\Security Options.
- 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.
- All Windows versions since Windows 2000 support Kerberos.
- Kerberos is the preferred authentication protocol for Windows 2000 and subsequent Active Directory domains.
- Kerberos is a domain only protocol, NTLM is used if authenticating to a system that is not on the domain.
- Kerberos requires a server name, so NTLM is used if a client is authenticating to a server using an IP address.
- Kerberos makes use of many different ports so passing it through firewalls can be fun if not previously familiar with it.
- NTLM, NTLMv2 and Kerberos all use the NT hash, also known as the Unicode hash.
Good advice based on what Microsoft allows, but unfortunately there is no way to remove the LM hash from memory. So the best way to truly eradicate LM hashes from the network are to enforce a >14 character password. More details here: http://computer-forensics.sans.org/blog/2012/02/29/protecting-privileged-domain-accounts-lm-hashes-the-good-the-bad-and-the-ugly
Thanks for the input Mike. I can verify this is correct and applies to domain accounts as well as local accounts.
Just thought I’d mention this typo:
> 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.
That key is actually:
HKLM\System\CurrentControlSet\Control\Lsa
Cheers, Ander