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 192.168.100.200:1812 
 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 = 192.168.101.249 
 20:36:15 radius,debug resending 58:2f8 
 20:36:15 radius,debug,packet sending Access-Request with id 32 to 192.168.100.200:1812 
 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 = 192.168.101.249 
 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!