Recently we had a customer who wanted to pilot the use of certificate-based authentication for their wireless network.
They had a new internal Public Key Infrastructure (PKI) capable of issuing required certificates and built a new Network Policy (NPS) server. Their wireless access points were Cisco Meraki devices, and the network team had created a new SSID with the relevant configuration on the network side.
The customer had Windows 10 devices and wished to have machines automatically connect to the new Wi-Fi network when in the office, only allowed on if they have the appropriate certificates present. They wanted to use PEAP with Certificates (EAP-TLS) which requires the presence of a computer certificate and a user certificate on the Windows 10 device and they wanted the Windows 10 devices to be able to authenticate to the Wi-Fi before user logon, so that various domain based scripts and processes were able to run before the user logged in. Currently they are using group policy to manage Windows 10 rather than Intune although this is coming in the near future.
So, the job was to make it work given the current setup. There are some reasonable bits and pieces of info out there about it, but we could not really find anything that collected everything in one place, so in this blog I’m trying to summarise the steps we performed in each area.
There were several areas we had to look at:
- NPS server configuration
- Group Policy (for deployment of wireless settings)
- Client certificates
- Meraki Configuration
This blog assumes some understanding of the components we configured and shows how we dealt with some of the “gotchas”. It may not be applicable for every scenario.
The following Microsoft article was used as a rough guide https://blogs.technet.microsoft.com/networking/2012/05/30/creating-a-secure-802-1x-wireless-infrastructure-using-microsoft-windows/
NPS server
The things to consider when configuring the NPS server (we looked at these as pre-requisite checks)
- The NPS server should be a domain joined server.
- It should be in the RAS and IAS servers AD group; this will allow it to enrol for a server a certificate from the RAS and IAS servers Certificate template (assuming this template has been published on your Certificate Authority).
- Following on from this, ensure the NPS server has the appropriate root CA / issuing CA certs in the appropriate local stores and there is an autoenrollment policy that enrols the NPS server cert from the RAS and IAS certificate template. If you don’t have a valid chain of trust you will hit issues, and if you don’t have autoenrollment you’ll need to remember to manually renew the NPS server certificate around the end of the validity period.
- The NPS server will need to be authorised in AD from NPS console.
- Enable NPS logging to full range of events can be seen in event viewer auditpol /set /subcategory:”Network Policy Server” /success:enable /failure:enable – a useful thing from another risual blog!
The first thing we did in the NPS console was create a RADIUS client for the Meraki Wireless Access point working with the network team – this is fairly straightforward; we gave the Radius client a friendly name, IP address and working with the network team entered a shared secret. This shared secret the network team generated was 60+ characters, it did not have any special characters just a mix of upper and lower case and numbers. Further down the line when testing connectivity, we found we were getting NPS errors Event ID 18 every time we tried to connect to the Wi-Fi.
This is indicative of a shared secret issue. I’m not sure where the limitation lies, the Meraki or the Microsoft side, but when we generated a 30-character secret and updated both ends, we no longer had an issue.
The following NPS settings were deployed via the setup wizard, which gave us two polices – a connection request policy and a network policy.
The rest of the Wizard was completed with default settings.
There is not a great deal to look at in the Connection Request Policy created. It shows the use of Wireless 802.1x and the requests being authenticated on the server.
In the network policy, we made sure that in the constraints that PEAP is the only authentication method and all the less secure authentication methods are unchecked and these settings reflect what was chosen in the NPS 802.1x wizard.
This should be sufficient configuration on the NPS server side.
GPO for Wireless settings
The following settings were configured in GPO to apply Wireless 802.11 settings to some test clients
In a GPO: Computer configuration > Policies > Windows settings > Security settings > Wireless Network IEEE (802.11) Settings
We created a new policy and gave it a friendly name and added a new Infrastructure profile to this. The SSID created on the Meraki was hidden, and the Profile name in this GPO is what the clients could see as a wireless network.
A couple of things to note here:
We had an issue when testing where we could see on the NPS server logs the computer account being denied certificate logon via NPS, but the user was granted. We found that in the GPO on the security tab of the profile, advanced settings, checking the ‘Enable Single Sign on’ check box and the radio button ‘Perform immediately before user logon’ sorted this issue . This setting specifies 802.1x authentication happens before user logon, and meant that we could see after this was applied a successful grant of access on the computer logon on the NPS server. After this when the user logged on, we could see that some computer-based scripts were running successfully as the domain connectivity was there though the Wi-Fi before the user logged on.
We also had an issue where sometimes the computer appeared to connect to the Wi-Fi profile at the logon screen, sometimes not it almost seemed like sometimes the network was there, sometimes it wasn’t. We used the check box on the connection tab of the profile ‘connect even if the network is not broadcasting’. After this was applied, the computer consistently always automatically connected to the Wi-Fi profile.
Clients and users
The Microsoft documentation states that if using PEAP-TLS to have User certificate and computer certificate; we did try testing without a user certificate deployed and got the error “You do not have a valid certificate” when trying to connect to the WiFi.
There doesn’t seem to be much guidance as to what certificate templates to use, so as a test we duplicated the default User and Computer templates in PKI. They both have uses of client authentication in their properties. For ease of management there should be some sort of autoenrollment mechanism configured in AD GPOs to get these user and computer certs out and also the root / intermediate certificates to clients.
Note also if in the Certificate templates, the option to publish in AD has been enabled, and the setting which says ‘don’t allow duplicate certificates against an account’ is checked then a user logging on to a second machine won’t get a certificate on the 2nd machine. May be something to look out for if you are having trouble getting certificates issued. Also remember if you are adding users and computers to groups then there may need to be a logoff / on or reboot to update permissions and a Gpupdate before you see a certificate in the appropriate personal store.
Meraki
We didn’t have much visibility of what the configuration was here but was assured for the Meraki we had it was up to date with all the latest firmware (this has bitten me before when working with 802.1x having creaking old network kit!). Also assured that the right ports were configured for communicating with the NPS server and there was nothing in the way.
As mentioned above we had the issue with the SSID. The Meraki was set to not broadcast its network SSID – we did find that checking the IEEE 802.11 GPO setting to “connect if network not broadcasting” seemed to solve the intermittent connectivity issues we had and connectivity to the new network at the logon sceen was consistent after that.
Summary
With this all in place, we were able to see:
- Client connecting automatically to the wireless profile at logon screen
- On the NPS server could see a granted event on Protected EAP / Smart card or other certificate against the computer account.
- User logged on; could see one of the customers own logon processes running as we would if the machine was connected to the wired network before user logon
- On the NPS server, could see granted event on Protected EAP / Smart card or other certificate against the user account
- The user could access network resources as per being on the corporate network, and the network team could see us connected on the Meraki side.
