Skip to main content
IT Connect

Information technology tools and resources at the UW

NTLMv1 Removal – Known Problems and Workarounds

Good Background

http://technet.microsoft.com/en-us/magazine/2006.08.securitywatch.aspx is worth a read to understand much of the background behind NTLM. But as good as that article is, it isn’t comprehensive. Referencing http://technet.microsoft.com/en-us/library/cc773178(v=WS.10).aspx (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 many 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. You then fix the clients, fix the servers, then fix the DCs. Then find out you missed some clients and servers. (smile)

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 (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
Addresses Problem ID
A The MacOS Safari browser relies on an obscure Mac OS config setting in the nsmb.conf file which Eric Kool-Brown has verified. See https://discussions.apple.com/thread/2369451?threadID=2369451 and http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man5/nsmb.conf.5.html
For step-by-step instructions: Enabling NTLMv2 on Mac OS-X
4
B Internet Explorer and Chrome (on Windows) rely on the Intranet zone configuration (see Control Panel: Internet Options) to determine what type of authN it uses. So customers will need to add the URLs of UW websites that leverage Windows Integrated authentication. Examples include: https://sharepoint.washington.edu, https://axweb.cac.washington.edu, reporting services for the enterprise data warehouse, and possibly many other URLs. You can add “Washington.edu” and “uw.edu” and likely cover all UW websites. 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. See How do I reconfigure NTLMv1 on my computer so it will work with the NETID domain? for a good write-up or follow the details here.

        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.

a) You can use a Set-LMCompatibilityLevel powershell script available here to apply the right configuration.

b) 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)

3. Or you can download and unzip the easily-clickable the registry value.

1, 2, 3
D http://support.microsoft.com/kb/2811487 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 noted at http://support.microsoft.com/kb/893318/en-us if running the OS noted and/or set the registry value noted. http://support.microsoft.com/kb/2811487 is a duplicative KB which notes the registry value.

NOTE: The MacOS VPN client doesn’t support NTLMv2. This means that even if you apply the above workaround, all Mac clients have no workaround. The only known alternatives are to use an alternative source of accounts with NTLMv1 (another domain or local user accounts) or to use 3rd party VPN software (client and/or server) possibly in combination with different VPN protocols.

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

Enter URLs for any UW website that leverages Windows Integrated authentication such as Sharepoint, Dynamic AX, reporting services for the enterprise data warehouse, or other websites. You can add “Washington.edu” and “uw.edu” and likely cover all UW websites.

See http://sivel.net/2007/05/firefox-ntlm-sso/ and http://kb.iu.edu/data/bahf.html for detailed descriptions.

6
H Edit /etc/samba/smb.conf on the client, you should add the following to the “[globals]” section:client ntlmv2 auth = yes

http://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html 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. See http://tech.its.iastate.edu/win2000/admin/AuthIssues.pdf, section entitled “Samba – General Issues” for an example.

11
I (i) See hotfix at http://support.microsoft.com/kb/957441. This needs to be applied to Vista/WS2008 server with services issuing the error message. 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 http://blogs.technet.com/b/askds/archive/2012/02/02/purging-old-nt-security-protocols.aspx.

 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. See http://icc.ifas.ufl.edu/ICCminutes/NTLMv2_Scan_to_folder_issues.pdf for an example Ricoh copier with this issue.

From Armand Bularoro:

For Ricoh, visit the following link for instructions on enabling NTLMv2:

https://kb.wisc.edu/page.php?id=22836

For Xerox, enter the IP address and path, as shown below:

http://[IP_Address]/diagnostics/NTLMSecurity.php.

From Diana Sartorius:

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: http://support.microsoft.com/kb/2701704 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 http://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:

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.

See https://kb.iu.edu/d/bccn for an example of this workaround noted in user documentation.

4, 7, 8, 9
R Null session behavior from win7/ws08r2 and beyond may be relevant: http://windowsitpro.com/blog/8-w2k8-r2-ad-upgrade-tip-ntlm-changes and http://technet.microsoft.com/en-us/library/jj852275.aspx
S Minimum session security setting may be important: http://windowsitpro.com/blog/8-w2k8-r2-ad-upgrade-tip-ntlm-changes and http://technet.microsoft.com/en-us/library/cc736506(v=WS.10).aspx

Potential sources of solutions/workarounds:

 

Notes