FIX: Network Policy Server (NPS) not receiving authentication requests from clients Windows 2019

Disclaimer

I have not found the solution myself. I eventually also searched Google for this problem and found that there are more people with this problem.

In this blog post I wrote out how to fix NPS not receiving authentication requests from clients with a detailed explanation.

Introduction

Yesterday it was clear again that we always need a complete test plan for all changes. I thought my test was pretty complete, but unfortunately I hadn’t seen it coming.

And yet I am happy that Ricardo and I found out that our test plan wasn’t complete when we implemented the change.

If you want to know more about this, go to paragraph ‘why do I always seem to forget something in my test plan?‘

If you just need a quick fix, please go to ‘HOTFIX: NPS not receiving authentication requests from clients Windows 2019’.

Let’s fix NPS not receiving authentication requests from clients Windows 2019.

The problem is that on Windows 2019, there is a bug in the pre-defined firewall rules of NPS that are configured during the role installation. Since these are pre-defined firewall rules, we cannot change them and we have to create new firewall rules.

To quickly hotfix this, use one of the options below.

• Option 1: Option 1 immediately opens all ports required for Radius.
• Option 2: Use option 2 if you messed up so much by troubleshooting that you have to start over.

To learn more about the bug, go to the ‘Full Explanation‘ section.

HOTFIX

Option 1

$Ports = 1812,1813,1645,1646
New-NetFirewallRule -DisplayName "NPS Allow inbound" -Direction inbound -LocalPort $Ports -Protocol UDP -Action Allow

Option 2 – I’ve already messed my NPS up and I need to start over.

• First open PowerShell as admin and run the following command:

Export-NpsConfiguration -Path <filename>

• Then remove the NPS role and restart the server.

Remove-WindowsFeature -Name NPAS -Confirm:$false
Restart-Computer

• Then install the NPS role and import the configuration with this command:

Install-WindowsFeature -Name NPAS,RSAT-NPAS
Import-NpsConfiguration -Path <filename>

• Open the ports with this command:

$Ports = 1812,1813,1645,1646
New-NetFirewallRule -DisplayName "NPS Allow inbound" -Direction inbound -LocalPort $Ports -Protocol UDP -Action Allow

It should work as intended again.

Full explanation

There is a tiny difference between Windows server 2019 and 2016 and lower.

The pre-defined NPS firewall rules are suddenly put on program svchosts.exe in Windows Server 2019.

You can see this in the screenshot. Left is W2019 and right is W2016.

Since you have multiple svchosts.exe, the firewall does not know which svchosts.exe to link this to. The SID is not included by default.

So the firewall drops your packets as you can see in the firewall logging as well:

2020-06-17 08:05:34 DROP UDP 10.1.0.25 10.1.0.50 55134 1812 53 – – – – – – – RECEIVE

They say that you can enable this with the following command in Command Prompt as admin, but it broke more for me and I eventually had to use option 2.

sc sidtype IAS unrestricted

Why do I always seem to forget something in my test plan?

We have an on-premise Network Policy Server that will be demoted in the near future and since we now have multiple work locations (Wortell and ETTU merge), we wanted to move the NPS to Azure.

We already have VPNs to all our work locations, so why not?

Let’s start with the implementation first.

I built 2 new virtual machines with the NPS role in Azure. It’s possible to Export your NPS configuration and Import this on your new servers:

Export-NpsConfiguration -Path <filename>

Import-NpsConfiguration -Path <filename>

I then enable logging on NPS via Command Prompt:

auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable

Let’s start testing!

I directly tested the Network Policy Servers via NTRadPing from the on-premise network.

With this tool you can fake a Radius request:

It doesn’t matter what you enter as long as your RADIUS server / IP is correct. If your NPS works, you will see a notification in your event viewer after logging is enabled.

The NPS event viewer is under:

Eventvwr > Custom Views > Server Roles > Network Policy and Access Services

Because I have not configured the management server as a radius client, I automatically receive an error message. This is EventID 13.

So, you’d guess it would work now, right?

We’ll think again,… NO!

We were supposed to enable the Azure NPS today. We adjusted this in our controller and tested it right away via our laptops. We did get the login prompt when logging in to the wifi, but it was reloaded over time.

We saw no EventIDs coming in on the NPS in the event viewer. The first thing I thought of was that the on-premise firewall was blocking the NPS ports 1812 and 1645 for outbound. This wasn’t the case, and it wasn’t the Network Security Group in Azure either.

The last thing I thought about was the local servers, but NTRadPing worked on the localhost, but not from NPS to NPS… Normally port 1812 and 1645 is opened for the domain profile after installing the role. In the end I turned off the Windows Firewall and we suddenly saw successful logins!

So it turns out to be a bug in Windows server 2019…

• https://windowsserver.uservoice.com/forums/295059-networking/suggestions/35724043-fix-default-nps-firewall-rules-for-server-2019
• https://community.ui.com/questions/FYI-Windows-Server-2019-NPS-for-RADIUS-broken-w-fix/364c7c17-b3d3-4973-8dd2-e4e701309300

How glad am I that we use the Start and Stop solution in Azure and after a restart it doesn’t work anymore. Now we found out during implementation.