Combining user and device certificates for wifi authentication in Intune

Passwords are a pain; that’s hardly news in 2024, but good old plaintext credentials do one thing very well: uniquely identify an individual on a network with minimal effort. Sure, they’re insecure, prone to user error and eschewed in modern wifi standards but supplanting them with the public key infrastructure required to switch to a more secure certificate-based method is no mean feat, particularly if user-level identification is to be maintained. A commenter in a previous post asked ‘why does this matter?’ and I promised an explanation so here it is!

host/xxxxxxxx, who dis?

The idea of a device that is directed by an MDM policy to enrol with a cloud CA and receive a certificate it then uses to authenticate itself onto the network without any human involvement is very appealing; not only is it vastly more secure than having users type passwords but it’s more convenient and reliable as well.

When I first got device certs working in my organisation I was elated, only to realise that my visibility of who was actually using a device had disappeared. I had substituted a list of usernames that could be recorded in activity logs or referenced by firewalls for policy application with a list of hostnames that gave no indication of who was behind the screen.

In some contexts this might be fine. For example a business may use an agent such as Palo Alto’s Globalprotect client to provide user identity, or perhaps just logging device activity will suffice. In an education context where we need to apply network and firewall policy at the user level though, authenticating devices is useful but authenticating users is essential.

I needed to retain authentication for devices (so the device has a connection at the logon screen and when the user is logged out) but add a user-specific method that takes over after login. Unfortunately this is much more complicated to implement than describe!

Intune setup

Intune is certainly capable of connecting the dots between a cloud CA (in my case SCEPman community edition, a certificate issued by it to a device or user and a wifi network. Indeed, the wifi policy template deployable from Intune contains an authentication mode option specifically for ‘user and machine’. This is described by the documentation as applying to precisely this scenario:

When a user is signed in to the device, user credentials authenticate to the Wi-Fi network. When no users are signed in, then device credentials authenticate.

Unfortunately there’s not much clarity about how to actually make this work. The wifi profile only gives the option of selecting one SCEP profile for the user-and-machine mode and given that a SCEP profile can only be for a user or a device and not both, that would seem to preclude its use.

Profile assignment

There is a trick to making it work though, and that’s using the following profiles:

Note that all of the profiles are applied to the device, apart from the SCEP trusted certificate profile which must include the user.

Digging through the 802.1x logs has shown that if a device has access to both a device and a user cert issued from the same CA and a wifi profile with ‘user and machine’ auth, the switch to the user cert will happen at logon.

See below image of the relevant settings in the profile:

Chicken-and-egg

There’s a catch though, and it’s a pretty obvious one. The first time a user logs in, the device may have a cert but they don’t (of course not; they haven’t logged in before). Windows needs some time to create the profile, sync with Intune to get the set of policies referenced above, request a user certificate via SCEP, then apply that to the connection. This would logically imply the need for a grace period at first logon; a few precious minutes during which the device would hang on to the machine-cert connection until it has fetched a user cert and can switch over.

Sadly this does not happen; there is no grace period or other means of sustaining connectivity past logon. The moment the user reaches their shiny new desktop, they’ve already lost their wifi connectivity as Windows looks for a cert that doesn’t exist yet and unsurprisingly fails to find it. At this point the user needs an alternative network connection (wired or wireless) or they’re left stranded – and even when Windows finally gets the user cert it won’t use it until it’s forced to by rebooting or reconnecting to the network.

Result

Providing that failsafe connectivity is afforded to the user and they are able to retrieve their certificate, from that point forward Windows will always authenticate using it. At login, the subject of the user cert is parsed and the network view of ‘host/xxxxxxxx’ immediately switches to ‘user@UPN’ and in terms of network and firewall events the username will be visible (providing that there’s telemetry from the RADIUS server to the firewall of course). It’s important to note that cert renewal should be set at an interval that’s longer than the longest time a user could be away from their device or they’ll be back to square one at that point.

TEAP answer? 🫖

The Tunnelled EAP (EAP-TEAP) standard is a potentially exciting option as it ‘chains’ the user and device certificates and authenticates them in a single EAP session, within which the failure of one method need not break the entire session.

The spec states:

The result of failure of an EAP method does not always imply a failure of the overall authentication. If one authentication method fails, the server may attempt to authenticate the peer with a different method.

That could mean something like a ’temporary network password’ the user can enter to bootstrap themselves back onto the network on their first logon (providing Windows has the ability to present them with a re-authentication prompt).

Some vendors (Cisco, Aruba) already allow for discrete failures within the session by providing remediation options (e.g. for machine pass and user fail). There’s a great blog from Wires And Wifi that goes into detail on this. If the RADIUS server can punt a client into a remediation VLAN with a session timeout of say 10 minutes, that could give Windows enough time to grab the user cert and also give it the nudge it needs to reauthenticate correctly.

Not all vendors are so flexible though; Extreme for example, states:

When using EAP-TEAP the primary authentication must be Computer/Machine authentication and the secondary authentication must be User authentication. Both authentications must also pass to send Access-Accept.

Either way, there’s no support in Intune yet. The only way to get a TEAP profile into a policy is to configure a reference device manually and export its settings to an XML file with the netsh command, then import that XML file to a custom profile – a fairly cumbersome process.

Hopefully we’ll eventually reach feature parity across all of the implementations and TEAP will provide the long-term solution we need for user-and-device authentication. In the absence of a redesign of Windows, it’s certainly as close as we will get.

Thanks

I’ve been swapping notes with the ever-knowledgeable @beamflash on this subject for years and many insights in this post are his. I am grateful for his friendship (and his brain). He will be speaking on this topic at the upcoming WATSSA conference on 2nd May; if you’re in Perth I’d highly recommend signing up!

I’m going to follow this blog up in coming weeks with a more practical one on my particular deployment using Juniper’s Mist cloud Wi-Fi technology.

Update 25/02/24

Shortly after I wrote this blog Oliver Kieselbach, one of the brains behind SCEPman, published a detailed writeup on integrating it with a cloud RADIUS service using Intune. While it’s only concerned with standalone device certs, it’s still a great read because it delves into the process in greater detail than I have here. Also shout out to Oliver’s SyncML tool which is very handy for general Intune troubleshooting.

Comments