Windows Server 2019 and NPS RADIUS Server

After getting Active Directory LetsEncrypt SSL Certs working in my homelab the other week, I wanted to configure NPS as a RADIUS server for my MikroTik CAPsMAN WiFi APs.

After I got everything configured up on both the NPS Servers and the CAPsMAN controller I tried to get a client to connect. I tried with an Android device first – there are rather a lot of config options for joining a WPA2-Enterprise access point, so when it failed to authenticate at first, I assumed I was just misconfiguring the client.

After trying every permutation I could reasonably envisage I decided to stop mucking about and start looking at logs! First I enabled radius debug logs on the CAPsMAN controller:

> /system logging add topics=radius

Then, reviewing the logs (with /log print follow) I saw a lot of this:

20:36:14 radius,debug,packet sending Access-Request with id 32 to 
20:36:14 radius,debug,packet Signature = 0x120b02548ff53181b0f167d8ac832ea6
20:36:14 radius,debug,packet Service-Type = 2
20:36:14 radius,debug,packet Framed-MTU = 1400
20:36:14 radius,debug,packet User-Name = "david"
20:36:14 radius,debug,packet NAS-Port-Id = "2G-pilue-ctrl-ap-loft-1-4"
20:36:14 radius,debug,packet NAS-Port-Type = 19
20:36:14 radius,debug,packet Acct-Session-Id = "82100022"
20:36:14 radius,debug,packet Calling-Station-Id = "F2-6F-A3-8C-31-4A"
20:36:14 radius,debug,packet Called-Station-Id = "02-0C-42-FC-F3-0E:Pilue-2G"
20:36:14 radius,debug,packet EAP-Message = 0x0201000a016461766964
20:36:14 radius,debug,packet Message-Authenticator = 0x489b54f28480c68f9575743b2ce59f27
20:36:14 radius,debug,packet NAS-Identifier = "pilue-ctrl-ap-loft"
20:36:14 radius,debug,packet NAS-IP-Address =
20:36:15 radius,debug resending 58:2f8
20:36:15 radius,debug,packet sending Access-Request with id 32 to
20:36:15 radius,debug,packet Signature = 0x120b02548ff53181b0f167d8ac832ea6
20:36:15 radius,debug,packet Service-Type = 2
20:36:15 radius,debug,packet Framed-MTU = 1400
20:36:15 radius,debug,packet User-Name = "david"
20:36:15 radius,debug,packet NAS-Port-Id = "2G-pilue-ctrl-ap-loft-1-4"
20:36:15 radius,debug,packet NAS-Port-Type = 19
20:36:15 radius,debug,packet Acct-Session-Id = "82100022"
20:36:15 radius,debug,packet Calling-Station-Id = "F2-6F-A3-8C-31-4A"
20:36:15 radius,debug,packet Called-Station-Id = "02-0C-42-FC-F3-0E:Pilue-2G"
20:36:15 radius,debug,packet EAP-Message = 0x0201000a016461766964
20:36:15 radius,debug,packet Message-Authenticator = 0x489b54f28480c68f9575743b2ce59f27
20:36:15 radius,debug,packet NAS-Identifier = "pilue-ctrl-ap-loft"
20:36:15 radius,debug,packet NAS-IP-Address =
20:36:16 radius,debug timeout for 58:2f8

…the important bit being that last line about a timeout.

So, of course I started by increasing the timeout of the radius config in the MikroTik:

> /radius set 0 timeout=1000

This sets the timeout to 1000 milliseconds (or 1 second). However this didn’t sort it. Next thing I thought was, is the MikroTik failing to talk with the NPS Servers? I’d recently completed a big re-architecture of my network at home (segregating IoT devices, wifi clients, etc) which included a load of firewall config on my pfsense router. I reviewed all my rules in pfSense and they looked correct, but still, I disabled the radius config for the NPS server in a different subnet to the MikroTik CAPsMAN controller just in case.

Still, no dice!

Then I thought to check the Windows firewall of my domain controller/NPS server. As I suspected, there is a default rule enabled as part of the install of NPS:

All looks good… grr! At this point I give up and start Googling! I’m not really sure what I’m searching for but hit the jackpot eventually with “server 2019 nps radius not working“. There are a number of top hits there that point to running the following command on the NPS server:

sc sidtype IAS unrestricted

Being the cautious kind, I attempted to understand what this command does. The cli help isn’t a lot of use:

If this setting is “unrestricted”, the Service Control Manager (SCM) will add this service’s service security identifier SID to the service process token when the service process starts the next time due to the first service in the process being started

What does that mean!? I’ll be honest, through all my digging on this command I’m still not terribly clear, but it seems that the default value in server 2019 of “restricted” places the SID of the service on a “restricted list” which prevents the windows firewall correctly interacting with the service. If I’ve got this wrong and you can clear this up for me please do let me know in the comments!

Ultimately, running the above command fixed my issue. Equally, so does creating a new inbound firewall rule identical to the default rule but without the service binding.

When I looked in to the command above it seems that this issue has been known about since at least 2018 and still not fixed by Microsoft. Poor show, that!

One thought on “Windows Server 2019 and NPS RADIUS Server

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.