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
19 comments
-
Seemonraj S
commented
Having same problem with ADK/WinPE 2004. Voting for this.
-
Dick Tracy
commented
While testing WinPE 1909 and 2004 (with dot3svc component enabled) it does not work. However when testing WinPE 1607 and 1703 with hotfix (https://support.microsoft.com/en-us/topic/windows-pe-network-winpe-dot3svc-optional-component-doesn-t-work-in-windows-10-version-1607-or-version-1703-8f392d99-c248-6148-39ab-6dc05fd49622); it does work. Is this the same bug in later versions?
-
Claudio Mendes
commented
+9999999 votes thanks and also fix the issue with the windows in place upgrades losing the 802.1x settings!
-
Anonymous
commented
I don't know if this is something that would be possible. You are asking for SCCM to provide a client at PXE boot with no OS with a certificate. Unless you can install the cert into the motherboard, I'm not sure how that would happen. If you are talking about during re-image, this would be an ADK change that's needed as you are wanting certificates to be added to the WinPE image.
-
Cristopher
commented
After many years, I'm seriously considering taking my 3 votes off this item as it's clearly never going to happen. I'd rather contribute my votes to something that has a chance of seeing the light of day.
OSD is more and more becoming of a legacy provisioning tool while Autopilot is being pushed harder and harder by MS.
In spite of great contributions from the community, we never got OSD to work in our 802.1x environment and even made some backwards progress when trying to work more closely with our network security team.
About a year ago we threw in the towel and stripped all 802.1x customizations from our OSD scenario. In spite of the incredible inconvenience it causes, all of our PCs get imaged or re-imaged on a dedicated network segment with no 802.1x.
-
Dave Wall
commented
Yes please! This is incredibly difficult in its current state. We are even having problems with Windows 10 in-place upgrade giving inconsistent results. We have implemented the recommendations from the excellent Adam Gross (SquareDozen). This isn't even supposed to be an issue: "According to the Windows 10 Product Group (via Microsoft Premier Support), an In-Place upgrade should migrate 802.1x settings." Adam Gross, https://www.asquaredozen.com/2018/07/29/configuring-802-1x-authentication-for-windows-deployment-part-4-integrating-802-1x-authentication-into-an-in-place-upgrade-task-sequence/
We are not allowed to MAC exceptions here, so for us there are many moving parts which make this very difficult to manage. We managed to get our Wipe and load OSD working, but it isn't pretty...
So anything that makes this process more friendly and less arcane would be welcomed!
Thanks. -
Espen Molund
commented
+1
-
Зеленов Владимир
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.