With the move to Windows 11, we are seeing more customers struggling to support their Wi-Fi connectivity. This is often caused by a legacy mindset using things like NTLM to authenticate to their wireless network.

I spent the last week or two going down this rabbit hole to figure out the best way to achieve it seamlessly with modern technologies powered by Microsoft Intune like Cloud PKI, policies, and more. Today, we will discuss how you can elevate your network connectivity seamlessly. We will be discussing:

• The Wi-Fi Issue We’re Trying to Solve
• Setting up a Meraki MR36 for the Network Policy Server (NPS)
• Using the NPS
• Integrating the NPS with Cloud PKI
• Deploying The Wi-Fi Policy with Intune
• Final Thoughts

The Wi-Fi Issue We’re Trying to Solve

Many companies on Windows 10 today have been using PEAP with EAP-MSCHAP v2 to automatically log into their network with the Windows logon name and password. This concept has worked well for a really long time. You can see that in the screenshot below:

When we move to Windows 11 and Cloud Native, this introduces a few issues:

1. Devices that are cloud native are no longer logging in with AD credentials that can be passed to the wireless network.
2. Credential Guard, which is enabled by default since 22H2 now secures the credentials with VBS (virtualization-based security) thus making them inaccessible to the rest of the operating system. This directly impacts things like MS-CHAPv2:

This creates a ripple effect throughout customer environments, which now needs a better solution. Over the next few sections, we will talk about the hardware I will setup and the process to modernize from legacy concepts to strong “modern” authentication with certificates and EAP-TLS.

Setting up a Meraki MR36 for the Network Policy Server (NPS)

Before we can start to solve all of life’s problems, we will setup the new AP that I bought. That AP is the Meraki MR36. The Meraki MR36 lets me use something called “RADIUS” aka Remote Authentication Dial-In User Service. Basically, RADIUS will let the access point forward authentication requests to “something” to perform authentication and authorization of access. That “something” is called NPS aka Network Policy Server, which is a Windows Server role (more on that later). The diagram below is a rudimentary idea around RADIUS:

In the video below, we will cover how you can easily onboard the Meraki MR36, setup the basics around RADIUS like adding the MR36 to NPS and making sure it can connect. It’s pretty easy. After watching this video, we will move onto talking more about NPS:

Using the Network Policy Server

So, the question is what exactly is NPS? I’m going to scope that tightly to what we’re focused on right now.

NPS lets you create and enforce network access policies for authentication and authorization. There’s other stuff you can do too like using it as a RADIUS proxy, but that’s not the point of this article. For our usage, NPS will be used as a RADIUS server and an accounting server (sending logs for troubleshooting).

This diagram below gives you a nice idea of what we’re dealing with here:

NPS uses AD-DS or the local Security Accounts Manager (SAM) user accounts database to authenticate users. This is done automatically as long as the device is domain joined.

Let’s look at the different components of it.

First, as you saw in the video, you create RADIUS clients with a shared secret to securely integrate/allow a client to interface with NPS:

We focus on two different policies. The first one is a “Connection Request Policy (CRP)”

The CRP is a gatekeeper, which decides whether the local NPS processes the connection request or forwards it to a remote RADIUS server. A CRP is basically a set of conditions and settings that will hopefully pass it along to the other policy.

In the overview, we enable the policy and if necessary, tell it if the Network Access Server is a RD Gateway or RAS:

Conditions get more interesting as you can basically specify conditions to decide if the request is authorized or not. You can use some of these different conditions:

• RADIUS client name filtering
• Client IPv4 and IPv6 Addresses
• Framed Protocol
• Service Type (e.g. Telnet or P2P) or Tunnel Type (e.g. PPTP or L2TP)
• Day and Time Restrictions
• SSIDs, and much more

We move onto Network Policies, which determine whether a device can connect to the network or not. You may have multiple policies, which it will evaluate from the top priority policy to see if it matches the criteria. If it doesn’t, it will keep going down until it runs out of policies and just rejects the request.

In the “Constraints” section of the Network Policy, we will set things like what EAP types are allowed, if insecure one is allowed, and other items. Similar items to conditions like idle session timeouts, day/time restrictions, and more are seen in here.

When we are doing EAP-TLS for example, we will just enable “Smart Card or other certificate” and disable these less secure methods like below to properly configure NPS:

In the video below, we will cover exactly how you build the EAP-TLS policy on your Network Policy Server to set the stage for our Wi-Fi awesomeness:

Integrating the NPS with Cloud PKI

One of the hardest parts about NPS is the documentation. Something that I struggled with when trying to leverage Cloud PKI was this damn error message:

So, I realized that something was off. I tried importing certs into almost every store imaginable, until I found some great documentation by Richard Hicks on importing 3rd party certs into the “magical” stores that NPS actually cares about. Essentially, you need to publish the 3rd party certificates to Active Directory. You can use certutil to do this and fix the trust issues. This is the code below:

certutil.exe -dspublish -f <path to Cloud PKI root CA certificate> RootCA
certutil.exe -dspublish -f <path to Cloud PKI root CA certificate> SubCA
certutil.exe -dspublish -f <path to Cloud PKI root CA certificate> NtAuthCA

Another issue I ran into was forgetting about the new PKI requirements around strong certificate mapping, which I solved as well was adding the SAN for the OnPremisesSecurityIdentifier. Otherwise, authentication will fail starting this month:

Overall, our PKI template should look like this:

You can now bring it all together and check out my video demo below, which even shows the successful manual auth:

Deploying The Wi-Fi Policy with Intune

We already saw that manually, the policy is working beautifully now. Let’s step through the Wi-Fi policy creation in Intune. You create the policy inside of templates is pretty simple once you have figured it out manually.

We set a few things:

• Set the SSID
• Set Auth Mode to User
• Set to EAP-TLS
• Specify the NPS server name for the server certificate trust
• Set the Root and SCEP certs

Overall, you can see a sample policy below. It’s a nice setup once you have sorted things out:

Final Thoughts

This was a very interesting thing for me to work on. Most people aren’t using NPS with EAP-TLS on Cloud Native devices. Many have moved to great Cloud RADIUS solutions like RADIUSaaS: Secure and Easy Cloud-Based Authentication for Network Access by the amazing team that created SCEPman.

Those solutions are neat because they integrate with Microsoft Entra and enable possibilities like Device auth, which is not possible with NPS. (Don’t come at me with your silly dummy object nonsense).

This is something I hope to bring to Workplace Ninjas because people really need help with certificate-based technologies, and this is another big challenge many struggle with. I hope this was helpful and look forward to lots of fun feedback.