01-16-2020 07:15 AM
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.
02-04-2020 10:02 PM
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.
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
02-05-2020 06:12 AM
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.
06-03-2021 10:19 AM
Has anyone successfully implemented the solution of MS autopilot and ise dot1.x authentication?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide