Home » Active Directory » (Solved) Authentication stops working after installing February 2019 updates

(Solved) Authentication stops working after installing February 2019 updates

After installing February 2019 updates to your Windows Server, the authentication in your web application may stop working. The users may experience a delay and then authentication error following the delay.

There is a known issue about these updates. You will find the root cause and solution for this issue.

Background

There is a registry setting that instructs the web server and domain controller which version of NTLM to be used. If the web server and DC are trying to use versions that are incompatible with each other, NTLM authentication fails. Updates set the preference to “NTLMv2 only” (Registry value is 3) which may cause an issue if the DC is not supporting it.

For example: If DC (or client) is set to the value of 1 (Send LM, NTLM and prohibit NTLMv2) and the server is set to the value of 5 (Only accept NTLMv2), this issue may occur. Please see this article for the descriptions of each value.

More information:

DCs determine the minimum security requirements for NTLM authentication between a Windows client and the local Windows domain. Based on the minimum security settings in place, the DC can either allow or refuse the use of LM, NTLM, or NTLM v2 authentication, and servers can force the use of extended session security on all messages between the client and server. This is either set locally on the client or DC (LMCompatibilityLevel) or can be dictated by Group Policy.

Looking for a way to fetch data from Active Directory in your .NET application? Check this post out: How to fetch data from Active Directory from your .NET application?

Solution for authentication issue caused by February 2019 updates

Quick solutions

A quick solution would be uninstalling these updates. However, I would recommend implementing a permanent solution.

Another quick solution is to use Kerberos instead of NTLM. If you want to enable Kerberos, please move Negotiate to the top of the Providers list in IIS. This may quickly solve the issue. Please note that Kerberos require certain configuration (SPN settings) to work. If they are not present, Kerberos will fail. Therefore, this solution may not work in this case or may not be a “quick” one.

Enable Kerberos authentication to fix KB4487026 issue

Permanent Solution

Install the corrective updates to solve this issue. For Windows Server 2016 Build 1607, install this update: 4487026.

If you are not able to install it for any reason, try to match the LmCompatibilityLevel value between DC and server. Check the values below and make sure there is no mismatch (Use the table in the link I mentioned)

In the domain controller:

  • Check the value of the GP policy setting below
    Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options\Network security: LAN Manager authentication level
  • Check the value of the registry key below
    HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

In the IIS server:

  • Check the value of the registry key below
    HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

Receiving HTTP 400 Bad Request error? Here is a common root cause and solution: HTTP 400 Bad Request (Request header too long)

Ned Sahin

Blogger for 20 years. Former Microsoft Engineer. Author of six books. I love creating helpful content and sharing with the world. Reach me out for any questions or feedback.

Leave a Comment