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