NTLMV1

Background

NTLM attacks are especially relevant to Active Directory environments. One of the most common attack scenarios is NTLM Relay, in which the attacker compromises one machine and then spreads laterally to other machines by using NTLM authentication directed at the compromised server. The best way to cope with NTLM vulnerabilities is basically not to use NTLM, but NTLMV2 is more secure.

Read this article to understand the background behind NTLM. But as good as that article is, it isn’t comprehensive. Referencing (see section entitled “NTLM Referral Processing”) will help you understand how NTLM logons work across a trust. Note that this is why you won’t find any NTLMv1 logons on any domain controllers. You will find most NTLMv1 logon events on the member servers that allow NTLMv1–those member servers are the key and you should target them as the point of leverage to identify which clients are using NTLMv1.

Disabling NTLMV1

Go to the GPO section Computer Configurations -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options and find the policy Network Security: LAN Manager authentication level. You can also disable NTLMv1 through the registry.

Known Problems

ID	Problem Description	Solution?
1	Client LMCompatibilityLevel configuration wasn’t compatible (e.g. XP default)	C
2	Member server has a LMCompatibilityLevel configuration that isn’t compatible. There are two scenarios here: where the member server is acting in the role of the client because the client passes the username & password to the member server and the member server gets a logon token on behalf of the client via impersonation. In this scenario, the client computer’s configuration isn’t involved–just the member server’s. where the member server is just part of the authentication chain for the client (see “detailed description of NLTM authentication process” below). This scenario also means that #1 is a problem, i.e. the client LMCompatibilityLevel is incorrectly configured.	J -> C
3	Domain controller from a trusting domain has a LMCompatibilityLevel configuration that isn’t compatible (where the trusting DC is acting in the role of a client)	J -> C
4	Mac browser incompatibilities on old versions (Mac OS client + Safari)	A or M or P
5	Chrome (on Windows client) browser configuration needed	B or M
6	Firefox browser (on Windows client) with Windows Integrated webserver (in general, not specific to NTLMv1)	G or M
7	Firefox browser (on non-Windows client)	M or N or O or P or Q
8	Chrome browser (on non-Windows client)	M or N or O or P or Q
9	IIS webserver with Windows Integrated enabled (in specific, with “Negotiate,NTLM” enabled)	L or M or P or Q
10	POP or IMAP based email clients & Exchange that have “Simple Authentication and security layer” enabled	E
11	MacOS/Linux computers mounting SMB Share	H
12	IAS server & MS-CHAPv2 (which uses NTLMv1 by default)	F
13	Routing and Remote Access Service & MS-Chapv2 (which uses NTLMv1 by default)	D
14	Any client is trying to perform NTLMv2 authentication to Vista or Windows Server 2008 based service. Receives error: “STATUS_INVALID_PARAM”.	I
15	Copiers using Windows Integrated authentication (details lacking)	K

Workarounds and Solutions

ID	Solution	Problem ID
A	If you are using an old Mac device and can't upgrade, the MacOS Safari browser relies on an obscure Mac OS config setting in the nsmb.conf file. For step-by-step instructions: Enabling NTLMv2 on Mac OS-X	4
B	Internet Explorer(soon to be deprecated) and Chrome (on Windows) rely on the Intranet zone configuration (see Control Panel: Internet Options) to determine what type of authN it uses.	5
C	Change the LMCompatibilityLevel value. Level 5 corresponds to “Send NTLMv2 response only. Refuse LM & NTLM.” and is the most desired state. Level 3 (“Send NTLMv2 response only”) is the minimum needed to continue to interact with the NETID DCs. How you go about setting the LMCompatibilityLevel depends on the existing configuration of the computer. If the computer is domain-joined, the best way is to use group policy. And there could be existing group policy that sets the LMCompatibilityLevel value. If so, the group policy value will override any value set at the local computer. The GPO setting is located at: Computer/Policies/Windows Settings/Local Policies/Security Options/Network Security: LAN Manager authentication level. If the computer isn’t domain-joined, there are several ways to configure this setting: via the registry, via the local security policy or via a script. Alternatively, to use the local security policy approach: Use “Start->Run” and type in “gpedit.msc” in the “Run” dialog box. A “Group Policy” window will open. Click down to “Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Find the policy “Network Security: LAN Manager authentication level”. Right click on this policy and choose “Properties”. Choose “Send NTLMv2 response only/refuse LM & NTLM”. Click OK and confirm the setting change. Close the “Group Policy” window. c) Or alternatively, you can manually use the registry: Open regedit.exe Navigate to HKLM\System\CurrentControlSet\control\LSA. Click on LSA If you don’t see LMCompatibilityLevel in the right window pane, then choose: Edit > New > REG_DWORD. Replace “New Value #1” with “LMCompatibilityLevel”. Double-click on LMCompatibilityLevel in the right window pane. Enter “5”. (hexadecimal or decimal doesn’t matter)	1, 2, 3
D	Describes how to force NTLMv2 in MS-Chapv2	13
E	Turn off “Simple Authentication and security layer” in the POP/IMAP based mail client.	10
F	Apply hotfix if running the OS noted and/or set the registry value noted. This is a duplicative KB which notes the registry value. NOTE: Upgrade the MacOS VPN client. This means that even if you apply the above workaround,	12
G	For Firefox browsers (on Windows clients): Enter “about:config” Locate: `network.negotiate-auth.trusted-uris` Note: this setting is the successor to the deprecated `network.automatic-ntlm-auth.trusted-uris`	6
H	Edit /etc/samba/smb.conf on the client, you should add the following to the “[globals]” section:client ntlmv2 auth = yes View the reference material on this configuration file. If you are mounting a share, you’ll also need to modify the sudo command to explicitly specify the security level.	1
I (i)	See hotfix.	14
J	Use this PowerShell script: Get-NtlmV1LogonEvents to determine if your domain controllers or member server is using NTLMv1, then C if needed. That powershell script assumes Windows Server 2008 or newer. If your DCs or member servers are Windows Server 2003 R2 or earlier, the only way to identify NTLMv1 use is via packet captures. If you need to use packet captures see here.	2, 3
K	There are some copiers whose default configuration doesn’t permit NTLMv2. In some cases these copiers need configuration, in others, they need a firmware upgrade to support NTLMv2. For the Ricoh MP 6001, the firmware NIB needs to be at least 8.72. The Ricoh version can be seen on the configuration page.	15
L	According to two sources, IIS doesn’t actually negotiate the highest authentication protocol possible when used in combination with some combinations of Windows OS and browser–but instead negotiates the worst. We’ve been unable to verify these claims due to the lack of detail in the claims. Those sources suggest one of two solutions. Solution #1: This is caused by problem #1/4/5/6, so apply solutions C/A/B/G as appropriate to all clients. Solution #2: Reconfigure IIS to “Negotiate” instead of “Negotiate,NTLM”. Solution #3: https://learn.microsoft.com/en-US/troubleshoot/windows-server/windows-security/authentication-package-listed-as-ntlmv1-security-audit-event describes a scenario (scenario B as labeled in that article) that may explain this behavior. If this is the case, then fixing the LMCompabilityLevel of the client is needful. Note that if the clients are non-Windows clients (or really old Windows clients) that the minimum security level may be an important contributor to the cause/solution. HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\MSV1_0\NtlmMinClientSec is the Windows location of that setting. Solution H (see above) may address some non-Windows clients.	9
M	Get Kerberos authentication working. If authentication is cross-domain, then you will need a forest trust (only 8 trusts of all trusts with NETID are not forest trusts). Kerberos authentication requires a valid SPN at each of the stops in the authentication chain (the client, the member server and the DC). In most cases, the SPN must resolve to the host it is for; the SPN can’t involve a DNS record that doesn’t exist or resolves somewhere else. Kerberos authentication is time-sensitive, that is to say that all of the stops in the authentication chain need to be within 5 minutes of each other. If a web browser is used, there is sometimes special configuration required to get Kerberos working with it. For example, IE requires that the URL is listed in the intranet zone. Workaround G is another example of this. To get Kerberos working on a Linux computer, you might find http://technet.microsoft.com/en-us/magazine/2008.12.linux.aspx useful.	7, 8
N	Choose a browser that can do NTLMv2. To our knowledge, Safari on MacOS is the only non-Windows browser combination that supports NTLMv2. See workaround A. Firefox doesn’t support NTLMv2 natively. On a Windows client, it relies on the Windows libraries to do NTLMv2. Chrome doesn’t support NTLMv2 natively. On a Windows client, it relies on the Windows libraries to do NTLMv2. Opera has never supported any NTLM protocol.	7, 8
O	There is an open-source “personal” NTLM proxy that includes NTLMv2 support for web authN that might be used as a workaround. See https://cntlm.sourceforge.net/. If someone tries this out, we’d like to know so we know whether it’s a working workaround or just a theoretical one.	7, 8
P	If you have an IIS web server configured to do Windows Integrated authentication with non-Windows clients (see problems #7 & 8), an option is to remove Windows Integrated authentication and enable Basic Authentication. If you do, make sure you require HTTPS, so passwords in transit have a secure channel. An alternative would be to remove Windows Integrated and explore ADFS or Shibboleth authentication integration. For more reading material on IIS authentication, see: http://msdn.microsoft.com/en-us/library/aa292114(v=vs.71).aspx https://support.microsoft.com/en-US/help/215383 https://support.microsoft.com/en-US/help/968867	4, 7, 8, 9
Q	If you have a web server (IIS or otherwise) configured to do Windows Integrated with non-Windows clients (see problems #7 & 8), your best bet may be to provide a 2nd website (with an alternate FQDN) on the same web server pointing to the same content. This 2nd website would provide Forms or Basic Authentication. You’d then tell customers with a browser that is incapable of doing Windows Integrated that the workaround is to substitute the 2nd FQDN for any instance of the 1st FQDN, and then provide their credentials. This workaround is tidier than workaround P, in that it doesn’t affect those clients who don’t have a problem.	4, 7, 8, 9
R	Null session behavior from win7/ws08r2 and beyond may be relevant: http://technet.microsoft.com/en-us/library/jj852275.aspx
S	Minimum session security setting may be important: http://technet.microsoft.com/en-us/library/cc736506(v=WS.10).aspx

Contact Us