Windows 2019, NPS and broken firewall rules (good job Microsoft...)

I have a love and hate relationship with Microsoft products. In one hand they integrate well to each other, they cover most of real life use cases and some products are even the best you can find from the field. On the other hand, the quality of documentation can vary a "bit" too much, logging varies from great to awful and there are really weird design decisions here and there.

One of these issues hit me hard a while ago when I was configuring a new environment for a customer. Win 2019 servers, Active Directory, Network Policy Server (NPS) and RADIUS authentication for accessing network devices.

Sounds simple and easy, right?? Just install the NPS role to the server, create some rules who can authenticate and that's it. Well.... As you already might guess, things aren't so easy in this land of ICT misery. I actually once said to a friend of mine that I'm not sure if my job leans more on to comical or tragical side....

But, let's move on.

After carefully verifying that the network works correctly between the network device and NPS server I started to get a bit frustrated. There were some IPSec tunnels and other things which complicate the routing of the packets, so I had to triple check everything. I even installed Wireshark to the NPS server so I could check that the packets were coming through. One of my biggest pet peeves in Windows systems is the lack of tcpdump. About 99,x% of times I just need to verify if the correct packet is coming in, I don't need to analyze the contents of the packets, or dig very deep. I just need to see if the packet can reach the server. And for this really simple use case Wireshark is like using a cannon to shoot a mosquito.

So. Wireshark showed that packets reached the server, and they weren't blocked by the local firewall. Still, nothing on the logs. And I mean Nothing. I double and triple checked that the log settings were correct. I removed security hardenings from the server, removed NPS role and installed it back again. I tried to install it to another server. No luck. The wall next to me started to have a hole because of my continuous head banging.


WTF?!? The default Windows Firewall rule for Network Policy Server Radius traffic in Win 2019 is paired not only with the port 1812 but also with the specific service. Which is not the NPS service. And installation of NPS creates this rule.


I'm not going to express my real feelings and thoughts regarding this, but you can guess that they weren't very positive.... Luckily this was billable work, so even though I had wasted a bit too many hours because of this error, from financial point of view it was a good thing! ;)

So, after creating a proper custom rule for the RADIUS traffic, everything started to work like a charm. I got data to the NPS logs and authentication started working correctly.

As I already wrote, many Microsoft products have problematic logging practices, and NPS is one of those. Basically it can write logs to a local text file (great) and also to an SQL server. But analyzing those text files is not so easy. There is too much data (read: XML in one line....) and the interesting error codes are just numbers. So you need to google what the error 35 or 66 means. Yes, log format should be simple and not too verbose. I just hope that they would offer a simple and easy log viewer for the data, so you wouldn't need to parse it by yourself.

I usually try to take these cases as learning experiences, just to stay sane. In hindsight it's really easy to see where I took the wrong path and how I should have approached this issue. But let's say that it didn't occur to me that the firewall rule which the NPS role installation creates is broken. Hopefully next time I recall this debugging project and can guess the correct path a bit quicker!

Comments

Popular posts from this blog

The only constant is change

Passion is a fruit

Hack the Box, CTF, challenges, and ethical hacking (+ some thoughts about courses)