Main menu (IT)



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. is worth a read to understand much of 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

IDProblem DescriptionSolution?
1Client LMCompatibilityLevel configuration wasn’t compatible (e.g. XP default)C
2Member 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
3Domain 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
4Mac browser incompatibilities on old versions (Mac OS client + Safari)A or M or P
5Chrome (on Windows client) browser configuration neededB or M
6Firefox browser (on Windows client) with Windows Integrated webserver (in general, not specific to NTLMv1)G or M
7Firefox browser (on non-Windows client)M or N or O or P or Q
8Chrome browser (on non-Windows client)M or N or O or P or Q
9IIS webserver with Windows Integrated enabled (in specific, with “Negotiate,NTLM” enabled)L or M or P or Q
10POP or IMAP based email clients & Exchange that have “Simple Authentication and security layer” enabledE
11MacOS/Linux computers mounting SMB ShareH
12IAS server & MS-CHAPv2 (which uses NTLMv1 by default)F
13Routing and Remote Access Service & MS-Chapv2 (which uses NTLMv1 by default)D
14Any client is trying to perform NTLMv2 authentication to Vista or Windows Server 2008 based service. Receives error: “STATUS_INVALID_PARAM”.I
15Copiers using Windows Integrated authentication (details lacking)K

Workarounds and Solutions

IDSolution   Problem ID

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


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.

CChange 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.
  1. 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.
  2. 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:

1) Use “Start->Run” and type in “gpedit.msc” in the “Run” dialog box.  A “Group Policy” window will open.
2) Click down to “Local Computer Policy -> Computer Configuration -> Windows Settings -> Security Settings ->
Local Policies -> Security Options. 3) 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. 4) Close the “Group Policy” window.

c) Or alternatively, you can manually use the registry:

1) Open regedit.exe

2) Navigate to HKLM\System\CurrentControlSet\control\LSA. Click on LSA

3) If you don’t see LMCompatibilityLevel in the right window pane, then choose: Edit > New > REG_DWORD. Replace
“New Value #1” with “LMCompatibilityLevel”. 4) 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-Chapv213
ETurn off “Simple Authentication and security layer” in the POP/IMAP based mail client.10
FApply hotfix noted at if running the OS noted and/or set the
registry value noted. 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,

GFor Firefox browsers (on Windows clients):

Enter “about:config”



 Note: this setting is the successor to the deprecated network.automatic-ntlm-auth.trusted-uris

HEdit /etc/samba/smb.conf on the client, you should add the following to the “[globals]” section:client ntlmv2 auth = yes is 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.

I (i)See hotfix at
JUse 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

 2, 3
KThere 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.

 LAccording 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: 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.

MGet 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 useful.
7, 8
NChoose 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
OThere is an open-source “personal” NTLM proxy that includes NTLMv2 support for web authN that might be used
as a workaround. See

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
PIf 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:

4, 7, 8, 9
 QIf 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
RNull session behavior from win7/ws08r2 and beyond may be relevant: 
SMinimum session security setting may be important: