by Marco Hofmann, CTA
Microsoft offers a nice set of security baseline GPOs, for direct use in your Active Directory environment. If you make use of the “MSFT Windows Server 2022 – Domain Controller” policy, your NPS installation might start to fail.
Introduction
Many of you probably have a Citrix NetScaler Gateway installation based on the following concept:
Manuel Winkel (deyda): Microsoft Azure MFA Cloud Service in Citrix ADC
Thomas Preischl: Citrix ADC / Netscaler Azure MFA Authentication
Those articles describe, how someone can implement Azure MFA with Microsoft Authenticator App pushOTP and an on-premises Microsoft NPS server, without making use of SAML, which is necessary, if you use the ICAProxy Gateway only license for Citrix NetScaler Gateway.
The Error
While implementing the Microsoft security baselines at a customers’ site, we also introduced the Domain Controllers security baseline called:
MSFT Windows Server 2022 – Domain Controller

A few minutes later, the external Citrix NetScaler Gateway authentication stopped working. Users would only receive the error:
Unknown username or password

Troubleshooting on the Citrix NetScaler Gateway through the aaad.debug showed the following error:
MS-CHAP error ERROR_AUTHENTICATION_FAILURE (691)

ERROR_AUTHENTICATION_FAILURE (691)
While the event viewer on the NPS server told us:
NPS Extension for Azure MFA: NPS Extension for Azure MFA only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User Marco.Hofmann with response state AccessReject, ignoring request.

The Solution
The errors weren’t helpful at all. We spent quite too much time searching for an indicator of what might be the issue. We knew it must have to do with the Domain Controller security baseline. Finally, we stumbled upon the following post from serverfault.com:
https://serverfault.com/questions/608227/authentication-via-radius-mschapv2-error-691
One of my colleagues was at a Microsoft conference having various discussions when it dawned on him that MSCHAPv2 relies on NTLM to generate the password challenges and responses. Now plain old MSCHAP and MSCHAPv2 (i.e. not EAP-MSCHAPv2 or PEAP) when used in Windows RAS services will use NTLMv1 by default.
As many of of you have already started to catch on, we, like many administrators, have disabled NTLMv1 on our DCs and as such the DCs will only accept NTLMv2 requests. This explains why the failure I continued to get was a “bad password” error. The password being sent to the DCs was in NTLMv1 format and was getting ignored.
This post then leads to a Microsoft article, with the solution:
For example, when you set this value to 5 (Send NTLMv2 response only. Refuse LM & NTLM), the DC won’t accept any requests that use NTLM authentication. When MS-CHAP or MS-CHAPv2 are configured, RAS in Windows Server 2008 R2 will default to NTLM to hash the password. Because the DC only accepts NTLMv2, the request will be denied.
Microsoft NPS on Windows Server 2019 and 2022 will use NTLMv1 by default, if you make use of MS-CHAPv2. And the MSFT Windows Server 2022 – Domain Controller security baseline will turn off NTLMv1 for your Domain Controllers, which will break your NPS server.
To enable NTLMv2 for MS-CHAPv2, you must set the following registry key on your NPS server, and restart the NPS service, and it will start working again:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Policy]
"Enable NTLMv2 Compatibility"=dword:00000001

I hope this will help someone else!
See more posts by Marco Hofmann here.
Not a member of CUGC? Join for free today!
Thank you so much. For a later very explainable reason this happened to us when rebooting the NPS servers. First time it happend we rebooted and everything worked again. Well, that’s fine. But then again.
We didn’t have all the symptoms as you described and the main thing was to be able to reproduce this problem.
What we did was point the Netscaler NPS loadbalancer to 1 NPS server and use this command line to change the domain controller. FYI: Systeminfo and checking the logonserver is not up to date. That is set at logon and doesnt change anymore.
Checking current DC: nltest /dsgetdc:domainname
Change DC on NPS-01: nltest /Server:NPS-01 /SC_RESET:domainname\DC01
So we found out: DC1 doesnt work, DC2 doesnt work, DC3 works. and the MS-CHAPv2 was the main difference because of hardening. Enabled the registry key and now DC1 and 2 are also working.
In my case the problem was related to users password. It consisted a question mark… and this somehow broke it….