The radius client is a WatchGuard firewall. Radius server is Windows Server 2012 R2. I used an SSL VPN hosted on the WatchGuard firewall to test the radius configuration which was 100% successful. MFA prompt is received and access to VPN is allowed. However, when I add the radius server to the IKEv2 configuration, I receive an authentication failure. There is nothing about the radius configuration on the firewall that is different, so it doesn’t make sense why it isn’t working. The error I’m finding is in event viewer>applications and service logs>microsoft>azuremfa>authz>authzoptch>Event 1, Authz “NPS Extension for Azure MFA: NPS Extension for Azure MFA only performs Secondary Auth for Radius requests in AccessAccept State. Request received for User xxxxxxx with response state AccessReject, ignoring request.”
I’ve followed the instructions here: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension-errors as well as any other article I can find.
If the NPS extension works for our SSL VPN, that verifies that the NPS server and extension is configured correctly. I wonder if there is something about the radius request from the firewall that is different. I’d appreciate any assistance.
SOLUTION: My Domain Controller was rejecting the MSCHAPv2 authentication. When the NPS server was sending the authentication, it was sending via NTLMv1. On the DC, go to Computer\HLM\system\currentcontrolset\control\lsa\lmcompatibilitylevel if you have a value of 5, it’s rejecting the NTLMv1 requests and only accepting NTLMv2. This was our issue. This is a group policy, so it’ll revert a few minutes after changing, so GP will need to be updated.
Are there any additional attributes that need to be configured?
What authentication method is configured on the NPS server? Try using PAP
u/abumusafps
I’m having this exact same issue. Did you find a solution?
I’ve tried that as well. This NPS server is configured exactly the same as another NPS server which is installed on the same server as AD. The only difference is that the server giving me the issue isn’t on a AD server. The key that I’m noticing here is that when I try to authenticate using SSL VPN, I can see an event log under server roles> NPS showing that an LDAP connection to AD was established. However when I use IKEv2, I get an audit failure in the security log showing unknown username or bad password, AND there’s no log for the NPS server establishing a LDAP connection to AD. So for some reason it’s like when WG sends the radius request, the server “for some reason” doesn’t know to contact AD.
I’m still struggling with this. I have two NPS servers. One is on my AD server, the other is just another server running Windows Server 2016. What I found is that it’s an issue with domain authentication. Both of the NPS servers are configured exactly the same. However, when I try to authenticate on the server NOT on the AD server, domain authentication fails. I will find an audit failure in the security event logs, and the telling issue is that under event viewer> server roles>nps I never see an event creating an LDAP connection to AD. Something about authenticating doesn’t trigger the server to create that LDAP to verify credentials with AD. I’m completely lost. My plan has been to slowly migrate people over to the NPS server to be able to manage people who may have issues. I’m about ready to just say screw it and do it over a weekend and just see how it goes on Monday. WG support can’t tell me why this is happening. I’m totally lost. The server is configured correctly which is why when I’m authenticating with the ssl vpn everything works. You can find the ldap connection creation and I get my Azure MFA prompt. Just absolutely lost…
u/dsp_pepsi I got it working finally! My Domain Controller was rejecting the MSCHAPv2 authentication. When the NPS server was sending the authentication, it was sending via NTLMv1. On the DC, go to Computer\HLM\system\currentcontrolset\control\lsa\lmcompatibilitylevel if you have a value of 5, it’s rejecting the NTLMv1 requests and only accepting NTLMv2. This was our issue. This is a group policy, so it’ll revert a few minutes after changing, so GP will need to be updated.