Cloud-Native, Modern Solution to 802.1x Network Access Control on Azure AD devices - Part One
I’ve worked with a number of organisations, helping them to achieve a modern desktop experience by strongly suggesting native Azure AD Join (AADJ) over Hybrid Azure AD Join (HAADJ).
Upon first glance, there are a number of blockers to AADJ. The majority of these blockers have solutions - a topic which I’ll blog about sometime in the future - but one that until recently, I’ve never found a great solution for, is 802.1x or Network Access Control (NAC).
This is part one of a two-part series. In this part, I’ll explain the problems with the current solutions to 802.1x and in part two, I’ll go through the deployment of the modern solution using Microsoft Intune and Cisco Meraki.
The current solution for 802.1x
The most common method of achieving 802.1x is via the use of Active Directory Certificate Services (AD CS) and Network Policy Server (NPS).
At a very high level, this works with a Group Policy Object (GPO) that configures the computer to automatically request and retrieve a computer certificate from ADCS. NPS is then thrown into the mix, with a policy to state that the device must present a certificate for itself, issued from the organisations ADCS root certificate authority. Finally, switch ports and wireless access points are configured to have RADIUS control the authentication to the network.
When a device connects to the network, either by physically plugging in or connecting to a wireless network, the access request is sent to the RADIUS server, which in this case is the NPS server. The RADIUS server then requires the device to present it’s certificate. If the device does not present this certificate, or if the certificate is invalid/revoked, network access is denied. The idea behind this is that the device cannot retrieve a certificate from ADCS unless it is joined to the organisations Active Directory and managed by Group Policy - meaning I can’t rock up with my laptop, plug in, and be free as a bird on the network, as my device is not joined to AD and managed by Group Policy.
The problems with the current solution
That all makes sense, right? Right.
So what’s the problem? The problem, is this:
AD CS, when implemented properly, requires a minimum of two Windows Servers. One of these servers (the root) is offline except for renewal of the other server’s (the subordinate) certificate and a few other times. This has a cost, both in terms of compute and storage - regardless of on-premises or in IaaS, and in terms of Windows Server licensing.
An NPS server is required - and if you’re doing things properly, you’ll want more than one for redundancy. The same compute, storage and licensing costs also apply here.
There’s a fair few servers involved. You’re going to have to spend time managing those servers, patching them, ensuring their availability, etc. That involves an individual doing that - when they could be working on other things which bring more value to the business, such as maximising the investment in Microsoft 365.
ADCS is tightly integrated with Active Directory - this adds a workload which will result in making the organisation even more dependent on AD and on-premises infrastructure.
The solution
Zero Trust, anyone?
I know some of you reading this will be thinking “Zero Trust! Zero Trust! Zero Trust!” and I can’t blame you. It’s a valid point - why do you need to secure your network if your office network is similar to that of a Starbucks guest network?
Well, the answer is simply because to most organisations, Zero Trust is a foreign concept. Sure, you can explain Zero Trust until you’re blue in the face - trust me, I have - but while lots of organisations are on or starting their cloud journey, they want to reap the benefits as soon as they can and free up their IT personnel for other tasks. This means that items like Windows AutoPilot are high on a to-do list and getting AutoPilot complete is often a key stepping stone in further modernisation, such as moving file shares to SharePoint/Teams, deploying Microsoft Defender for Endpoint, and utilising device compliance state in Conditional Access.
Finally, some organisations have legitimate reasons for 802.1x.
This means that we have to reach a middle ground - but while trying to make sure that the solution is still a modern one. After all, who wants to be deploying ADCS and NPS and other on-premises infrastructure (even in Azure!) in 2022?
SCEPman and RADIUSaaS
I feel the solution is two products from a Microsoft Partner in Germany - Glueckkanja-gab. The two products they offer are SCEPman and RADIUSaaS. If you’ve ever had to deploy the traditional/current solution for Intune, you’ll recognise the term SCEP. SCEP stands for Simple Certificate Enrolment Protocol and is a certificate management protocol that is used for issuing certificates automatically.
SCEPman
SCEPman is a cloud-based PKI, that runs in your Azure subscription using Azure App Service and Azure Key Vault. This means that you do not have to worry about any of the items I listed above, but still have a PKI. Instead of configuring your devices to retrieve a certificate from ADCS, you configure them to retrieve a certificate from SCEPman instead. The root certificate generated by SCEPman is stored in Azure Key Vault and Microsoft Intune is utilised to perform the following:
Deploy a device configuration profile that adds the SCEPman root certificate to the device’s trusted root certification authorities store.
Deploy a device configuration profile that configures the device to connect to the SCEPman service to receive a device certificate.
RADIUSaaS
RADIUSaaS is a cloud-based RADIUS service that runs in Azure. It’s hosted by Glueckkanja-gab rather than hosted in your own Azure subscription. Instead of configuring your network devices to send RADIUS traffic to your on-premises NPS server(s), you configure them to send it to RADIUSaaS. RADIUSaaS is configured to trust the SCEPman root certificate, meaning that if a device presents a certificate issued from SCEPman, it will be allowed network access.
The two products work together to provide a cloud-native solution to 802.1x. This solution allows an organisation to decommission ADCS and NPS - provided they’re not used for any other function - and focus on other items which are both more interesting and of more value to the organisation.
What next?
If you’ve made it this far - well done.
I’m currently producing part two of this series, whereby I’ll be demonstrating how to configure SCEPman and RADIUSaaS, integrate with Microsoft Intune, and configure Cisco Meraki wireless and wired networks to perform RADIUS authentication to RADIUSaaS. So stay tuned!
While you wait, I’d highly recommend checking out the documentation on SCEPman and RADIUSaaS.
As always, feel free to leave a comment below.