Those of you who have been following my blog know that I have been working for years on finding a way to provide enterprise-grade on-premise network access for cloud-based devices. Microsoft has continued urging their customers to move entirely to the cloud for better security and simplified management but for many this gap is insurmountable. I previously presented a workaround for reverse-engineering cloud compatibility into their legacy NPS product and have been on a quest to find a better way of doing this ever since.
I recently returned to Australia to set up a proof of concept deployment of Mist Systems in a production network with 18 APs and >300 clients; this is the closest to a complete answer that I’ve seen so far and certainly the simplest and most accessible. I’m not shilling for it or promoting it as best for every environment (I’d love to see a greater range of options, particularly at the lower end of the cost scale in order to make ditching legacy on-premise infrastructure more tempting to a broader range of organisations) but I hope that sharing what I’ve done may be of use to others in similar circumstances.
Enter Mist
I had some vague prior awareness of Mist but hadn’t taken a close look until a friend mentioned they were interested in making the education market a greater focus. I contacted them to see how their designed-for-the-cloud systems would work in this scenario, fully expecting to be disappointed. To my surprise they had a trick up their sleeve in the form of a cloud NAC. This nifty little extension (it’s sadly not part of the base product) can take a device through the entirety of its authentication journey without reference to an external RADIUS or LDAP source, providing a rich set of policies for a wide range of scenarios. This differs markedly from something like Meraki, which is capable of only the most rudimentary of checks in this mode. The underlying technology came out of an acquisition and was only released in mid-2023, mere months before my testing began. Since the real value for cloud-based devices lies in this NAC integration, that’s what I’ll focus on in this post.
PoC Setup
Here’s a (very) rough overview of my proof-of-concept environment. I have an Intune-managed client that’s directed to register for a device and user cert from a cloud PKI via SCEP (more on that side in my my previous post), a wifi profile that binds the SCEP cert to an SSID with EAP-TLS, and then on the Mist side there’s a cloud-managed AP which talks to the cloud NAC using RADSEC with it in turn trusting the CA issuing the certs to the users and devices.
A rose by any other name?
In the Phoebe and Her Unicorn comics, nobody ever takes notice of the titular unicorn (Marigold Heavenly Nostrils) not because she’s invisible but because she can project a Shield of Boringness that makes anyone who sees her forget about her immediately and forever. I’m not kidding when I say that exact effect keeps happening to me with the Mist cloud NAC because its actual name ‘Access Assurance’ is a literal Shield of Boringness (if you doubt me, I challenge you to remember it five minutes after you finish reading this post; in the meantime I’ll keep calling it the cloud NAC so you don’t fall asleep before you get there).
Fortunately what it does is anything but dull; it’s able to sidestep the need for a RADIUS server by evaluating the context and characteristics of authentication requests and make policy-driven decisions based on them. Here’s what the configuration looked like at the initiation stage of my PoC:
Each of my 5 profiles has a set of criteria it will evaluate; a matching client will be accepted and assigned to the linked policies. To keep things simple for the PoC, my profiles are all certificate-based using EAP-TLS and will match either device or user certificates.
Cert fields that can be used for criteria include the SAN, CN, subject, serial number and issuer. The issuer is a basic requirement that makes sure the client is using a cert from my CA; the SAN is where the magic happens. Since it can contain muliple URIs, it can be used as a tag, enabling a device or user to have additional bits of information included on their certificate that can be parsed during authentication.
With a URI tag specified in a SCEP profile assigned to a device group in Intune, the cloud NAC can match those specific devices to a policy. This is really nifty because it obviates the need for a directory of devices that has to be queried to see whether a device is valid and which policy should be applied; the answer to both of those questions is presented by the client itself. This can also be done with user certs, though in my case I’m using a wildcard match with the CN to separate my groups of users, since their UPN suffix is different. The sheer convenience of running all of these authentication outcomes through a single SSID is delightful.
Mist’s support for tags is limited at the minute and it will only parse a string in UPN format rather than recognising the tag: attribute. I’m using dummy UPNs as tags for now; Mist tell me they’re working on full tag support for a future release.
Hard vs soft-fail
So if we’re not authenticating against an external server, how do we know we’re authenticating valid devices? Firstly, we can enable OCSP on our cloud CA so that it can provide an immediate assurance to Mist that the certificate it’s authenticating hasn’t been revoked. SCEPman Community Edition will optionally revoke a cert when a device either has already been or is in the process of being retired, wiped or deleted (Microsoft’s Cloud PKI doesn’t support this yet but I’m sure it’s in the pipeline). This is a useful hard-fail, since those devices should certainly be excluded. While it may also be possible to extend this OCSP check to include device compliance or user risk (SCEPman Enterprise Edition is capable of this), the problem with doing so is that there’s no remediation path available if the wifi is flat out blocked for non-compliant or risky devices.
Helpfully, Mist’s brand new Intune integration caters for this exact scenario. Once linked with the Intune tenant, Mist can check device compliance status and auth profiles can be configured to match compliance status to policies so that specific actions can be taken for non-compliant devices. This can be managed differently between profiles; for example, my student devices will be blocked but staff devices granted access to a remediation network. Aside of the practicality of having a range of options for managing non-compliance, there’s an additional security benefit over OCSP in that the compliance status of devices is checked continually, rather than simply at logon.
A note on cost
Possibly the most canny thing about Mist’s cloud NAC is the way it’s licensed; where standalone cloud-hosted authentication services generally work on a flat per-user-per-month fee, Mist looks at the “average concurrently active client devices seen over a 7-day period”. This means if you’re a school with thousands of devices, you’re likely not buying thousands of licenses but a few hundred. Equally if you’re a business with a large amount of remote workers (and which isn’t these days), you’re not having to license the entire workforce just in case they happen to pop into the office. For my organisation, the cost of Access Assurance versus running multiple on-prem RADIUS servers across several campuses was an absolute no-brainer.
To be continued…
There are several areas Mist have confirmed for improvements in coming months aside of the RFC4151 compatibility for tags I’ve already mentioned:
Firewall integration
By far the biggest drawback to incorporating a cloud NAC is that typically the on-prem RADIUS or LDAP server is where a corporate firewall will get its user ID (the awareness of which user is at which IP address so it can apply network policy correctly and log user activity). Without accurate userid, a firewall can only apply policies based on source network which is simply inadequate for most organisations. Fortunately Mist were quick to grasp the urgency of this change; I worked closely with them and our partner to scope the requirements and it is currently one of their top priorities, though not likely to land in a public release until the far side of the summer.
EAP-TEAP
As discussed in my previous post, this could be a major improvement to the client experience and is on Mist’s roadmap for April with support for partial (machine-only) and complete (machine-and-user) chained auth.
Intune improvements
This will be extended to cover more detailed integration such as group lookups which will make the cloud NAC policies much more flexible and powerful, rather than having to rely entirely on certificate fields.
I’ll definitely keep this post updated on progress!