Self-deploying Intune Autopilot, remediation vlan and ISE

[BastiaanSc]

Currently struggling to get this to work correctly.

Situation:

Our self-deploying Windows 11 machines (autopilot and Intune) boot up and will start the deployment process. However because failing to authenticate and get redirected into our internet enabled remediation VLAN takes a couple of seconds, Windows will treat this as not having network connectivity.

This breaks self-deploying mode for us. As soon as the machine enters the remediation VLAN the Windows OOBE environment will show network connectivity and a button displaying "Next" will appear, picking up the self-deploying mode. After that, the machine gets a certificate and 802.1x wired profile succesfully connecting to a certificate-based policy VLAN.

We've already tried setting the authentication policy order to certificate - MAB or MAB - certificate and set the tx timeout to 1 second.

Is there anything else we can try?

[Arne Bier]

How did you expect the NAC server to handle this situation? Clearly 802.1X will not authenticate on a fresh machine, so you're left with MAB auth.  And what Policy Set Authorization logic should be used to handle a brand new, out of the box PC?

The issue you describe is common in other scenarios too, where something foreign is plugged into a LAN interface, and the RADIUS server has to try figure out how to handle it. The MAB Policy Set is where ISE will end up processing these Authorization Rules and none of them will match - inevitably you will end up at the bottom of the Rules list - here you can perhaps do one of two things:

• Authorize the Endpoint if its MAC address is found in an Endpoint Identity Group (e.g. a group called 'PXEBoot' or whatever) - this means of course that you need to add the new PC Ethernet MAC addresses in there before the user plugs them into the network. Perhaps you can get this data from the PC manufacturer in advance? Then create a purge rule that deletes these endpoints after 1 day.
•  Authorize the Endpoint in the penultimate Rule, if "Endpoint Authenticated" OR "User Not Found" and send back Access-Accept and a remediation VLAN, and dACL (if needed). The trick is of course to avoid having the PC perform DHCP and get a response back on the VLAN ID that is configured on the interface.  So, e.g. if you have interface gig 1/0/1 with switchport access vlan 99, then ensure that access vlan 99 is a dummy vlan that goes nowhere. If the PC sends a DHCP Discovery it will get no response. By the time ISE returns remediation VLAN X to that interface session, the PC will hopefully still be sending DHCP Discovery, but this time the Offer will be returned and then the PC will be on the remediation VLAN with a valid IP. The key point is that you should not return Access-Reject to unknown endpoints. This remediation VLAN should not allow intranet access - it should be internet access. Of course that would open up a whole other can of worms ... now you have created guest internet access for any unknown devices!!! Maybe that's acceptable?  Maybe not.  How is ISE to know the difference between Little Johnny's hacking device and a legit new Win11 PC? Profiling is not the answer, because the bad actor could also be using Win11 - therefore, operating system is no indication of good intent.  

I'd say MAC address is the only sure way to onboard these devices - and since Autopilot is a smart system, I'd be surprised if you couldn't get the PC's Ethernet MAC address electronically, in advance - and even feed them into ISE via API.

[BastiaanSc]

Hi Arne,

Thank you for your insightful reply. The way it's set up now is exactly how I imagined NAC and ISE would work. A fresh machine has no certificate and is not a member of local ad OU, so ISE won't authenticate it. This is exactly how it should be. 

Because of this we've set up a remediation LAN without intranet access, but with internet access. Exactly as described in your second scenario, which is acceptable in our situation. Both guest WiFi and guest LAN are on a separate outside connection to our corporate (W)LAN.

Our issue purely exists in these few seconds between authenticating and remediating into our guest vlan. This also happens when we've manually tested by adding the MAC adress of a single machine into MAB.

I will look into the DHCP trick, this might solve our problems!