ISE+IBNS and Microsoft out of box experience/auto-pilot

[joplant]

I have a customer currently deploying ISE+IBNS with dot1x and MAB on the LAN.  Their desktop team is looking to start moving towards a cloud based kick start of their corporate Windows 10 devices.  That process is described here: https://oofhours.com/2019/07/08/what-happens-when-a-windows-autopilot-registered-device-starts-up/

We are looking at options to minimize impact to the user experience when connect to a dot1x enabled LAN port.

It seems the options are:

Utilize a proxy via either DHCP or DNS with WPAD and allow access to the proxy via the pre-auth and/or auth-fail ACL

Allow all of the associated MS auto-pilot and in-tune addresses in the pre-auth or auth-fail ACL.

Utilize web auth as a third authentication mechanism

Just wanted to reach out to see if anyone has dealt with MS auto-pilot / OOBE already and how they approached it.  Each of the options above has some trade-offs and not sure which we'll end up utilizing.

The process itself just assumes full IP access for a base OS without any security configured.  This is not exactly compatible with a zero trust mindset.

[Greg Gibbs]

Hi JD,

I doubt anyone has tackled this yet. I suspect this is going to be really difficult to solve in a Wired NAC environment. You'll probably have to work with the customer to really break down each stage and determine what information ISE sees from the endpoint to see if there is some custom profiling policies that can be used to identify a Windows PC in an autopilot stage; similar to what I discussed in the following post with a PXE/SCCM build.

https://community.cisco.com/t5/identity-services-engine-ise/pc-imaging-on-nac-secured-ports/td-p/3486098

It's not clear from the documentation I've seen so far if the Windows PC will have a full browser during the autopilot stages, so that would determine if any WebAuth options (wired or wireless) would be possible.

Depending on what security is built into the autopilot flow itself, I suspect the easier option would be to leverage a cellular or Wifi option to provide public internet access to complete the initial stages of the build. You could maybe look at using a separate build SSID that uses a rotating PSK, or even a separate Guest Portal that uses SAML IdP integration with Azure AD (this integration may not work with current versions of ISE).

Hope that helps. It would be interesting to see what solution you come up with around this as I'm sure we'll start to see more customers moving this way.

Cheers,

Greg

[joplant]

Thanks Greg!

Had a meeting with the customer and MS yesterday and were told that the machine in that state does not have capability to handle web-auth, however, it may actually be able to utilize a proxy server.

We settled on a few options. 

1 - If the process can support a proxy server, we can utilize a pre-auth ACL and/or auth-fail ACL to allow access to the proxy server addresses.  This would allow the machine to reach out to any required addresses on Azure.

2 - Provide "internet only" for auth-fail/auth-timeout.  This opens other security risks and would be difficult to limit to pre-deployed machines in an automated fashion.  Restricting this type of access might be possible if it could be identified via profiling but certainly complicates the deployment.

Another option that was less desirable for this customer was having their vendor pre-deploy certs for the MS image or build a process for temporarily adding the MAC address of the host to the MAB database prior to deployment.

[raymondmf]

Has anyone successfully implemented the solution of MS autopilot and ise dot1.x authentication?