Native 802.1x Support for Enterprise Operating System Deployments
Provide Support 802.1x Natively w/o the use of prestart up scripts in WinPE. Many large organizations have protected network infrastructure for their environments that want to be able to easily utilizes the Deployment feature on these protected networks.
Steven
shared this idea
12 comments
-
Зеленов Владимир
commented
+1
-
Christoph
commented
agreed
-
Cristopher
commented
For those of you following this, here's a great blog series to assist with 802.1x deployments covering various scenarios.
http://www.asquaredozen.com/2018/07/29/configuring-802-1x-authentication-for-windows-deployment/ -
Herman van Drie
commented
I would rather see that WiFi support (Wlan AutoConfig service) introduced into WinPE, which is already present in WinRE for Windows 10.
Also, I would love to see that OSD status messages are able to be delayed when connectivity is not present (yet) using a TS variable.I was able to utilize WinRE with some coding of my own to allow OSD to fully run over wireless with deployment set to "Access content directly from a distribution point when needed by the running task sequence" so it would not require pre-caching.
See my tweet here: https://twitter.com/hvandrie/status/875303380977164288
In the corporate environment I work for this resulted in bare-metal installations using USB media as start up to boot WinPE media to initiate the deployment in less than 70-80 minutes using a 802.11ac network. Which was faster than fast ethernet!
-
Travis Vieson
commented
I agree. ADK 1607 and 1703 both need KB4025632 to work. What would be nice is an option when creating the boot image/media SCCM to use the PFX specified for 802.1x authentication. In a native environment I already need a certificate to communicate to SCCM, why not have an option to use the same certificate throughout the TS. At least then I only need to worry about cleaning up certificates at the end versus getting the system to build.
-
Raphael Jülich
commented
We just rolled out 802.1x and we are heading for a Solution where we use Orchestrator to create the SCCM Object and also create a MAC Exception on the Radius Server. After the TaskSequence has finished, the Orchestrator removes the MAC Exception again and everyone is happy!
-
Cristopher
commented
Fingers crossed that 2017 will bring some support to WinPE and SCCM task sequences so that we can do some OSD on a network that uses 802.1x security.
-
Mats
commented
We have the benefit of being able to use Mac authentication bypass for the OSD phase and we do switch to native 802.1X late in the OSD TS.
Would I like to see a better way? Yes - Also stop blocking GPO:s during OSD or make it selectable. The claim that GPO:s has to be blocked for OSD to work is a piece of BS. MDT do work with GPO:s
-
Cristopher
commented
We're headed backwards here. The latest WinPE 10 (version 1607) broke the dot3svc service. https://social.technet.microsoft.com/Forums/en-US/win10itprosetup/thread/93f32a23-7558-4742-91ab-ba0e7801ed0e/#3853df61-8dcf-4560-8b01-27da4fcca235 Those of you who are in an 802.1x environment, help me make some noise on this please.
-
Dustin Hedges
commented
Each 802.1x implementation is different. We essentially "hack" ours together in both WinPE and FullOS to get things to work. We leverage a combination of User Account Auth and Certificate Auth (where appropriate) and that's ONLY because we are essentially forcing our Information Security department to allow it.
Not every implementation is the same. And not every site, at every company, has the luxury of a dedicated "Imaging Lab" that can be exempt from 802.1x policies.
-
Gerhard Eriksson
commented
We are looking into if we can utilize Intel AMT so that authenticate the PC on our network because of lacking support for 802.1x. For the time being We use same method as Cristopher.
-
Cristopher
commented
We have 802.1x on our network and in order to achieve a successful operating system deployment we have had to implement hacks upon hacks into our process. I've gone through 2 dozen iterations of our boot image trying to get the script "just right" and it is still not 100% functional. Because of this, most of our deployments are still done on an isolated network segment where 802.1x is disabled.