Introduction
THANK YOU MICROSOFT!
Anyone who has had to support developers and IT Pros alike running Hyper-V on their clients and test systems in an environment with 802.1x port authentication knows the extra effort you had put into workarounds. This was needed due to the fact that the Hyper-V switch did not support 802.1X EAPoL. Sometimes it was an extra NIC on non-authenticated ports, physical security for rooms with non-authenticated ports, going Wi-Fi everywhere and for everything etc. But in conditions where multiple interfaces are a requirement, this becomes impractical (not enough outlets, multiple dongles etc. or add in cards).
On top of that, there was always at least someone less than happy with the workaround. 802.1x Support with the Hyper-V switch looks like it could or should work when looking at the vNICs both on the host and inside the VMs. You’ll see that the authentication properties are there, the policies to make it all work are pushed but no joy, authentication would fail
802.1x Support with the Hyper-V switch is here!
Windows Server 2019 LTSC (1809) & Windows 10 (1809), as well as the 1809 or later SAC versions, now offer 802.1x Support with the Hyper-V switch.
This is not enabled by default. You will need to add a registry key in order for it to be enabled. Form an elevated command prompt run
Reg add “HKEY_LOCAL_MACHINE\SYSTEM\CURRENTControlSet\Services\vmsmp\parameters” /v 8021xEnabled /t REG_DWORD /d 1 /f
This change requires a reboot. So, we also give the Hyper-V host a kick
shutdown /r /t 0
When you have a Hyper-V switch that you share with the management OS you will see that the management vNIC now authenticates.
You can also authenticate VMs. Depending on your needs the configuration and setup will differ. 802.1x allows for Single-Session/Single-Host, Single-Session/Multiple-Host, Multiple- Session (names, abilities vary with switch type, model, vendor) and you’ll need to work out what is needed where for the scenarios you want to support, you won’t have one size fits all with port authentication. I’ll be sharing my experiences in the future.
The point is you’ll have to wrap your head around port authentication with 802.1x and its various options, permutations on the switches and radius servers. I normally deal with Windows NPS for the radius needs and the majority of my sites have DELL campus switches. Depending on the needs of the users (developers, IT Pros, engineers) for your VMs you will have to configure port authentication a bit differently and you’d better either own that network or have willing and able network team to work with.
Conclusion
Hurrah! I am a very happy camper. I am so very happy that 802.1x Support with the Hyper-V switch is here. This was very much missing from Hyper-V for such a long time the joy of finally getting makes me forget how long I had to wait! For this feature, I will shout “BOOM”!
With the extra focus on making Hyper-V on Windows 10 the premier choice for developers, this had to be fixed and they did. There are a lot more environments in my neck of the woods that leverage (physical) port authentication via 802.1x than I actually see IPSec in the wild. It might be different in other places but, that’s my reality. With ever more mobile and flex work as well as body shoppers, temp labor that bring their own devices I see physical port authentication remain for a very long time still.
I have attempted this over and over in my Lab and have yet to be successful. I am curious if you would mind sharing some additional Hyper-V settings with me and also anything additional you might have had to do to the host to get it to work. I am using Cisco ISE and Cisco switches in my setup, but functionally, it shouldn’t matter. When I capture the the traffic on the port, I see the EAP request from the switch, but with the Hyper-V vSwitch configured for External, I get no EAP Response. I have added the registry key as indicated. Verified the key was added. Rebooted over and over. I am running Windows 10 Pro 1089. I have disabled the default vEthernet Default Switch. Again, no matter the configuration, 802.1X continues to fail to respond on the vSwitch. If I disable the vSwitch and let the NIC take back over, I get 802.1X and EAP Response right away.
Thoughts? Any help would be appreciated very much.
You have a typo in your registry key entry and that’s why it didn’t work for me.
Reg add “HKEY_LOCAL_MACHINE\SYSTEM\CURRENTControlSet\Servcices\vmsmp\parameters” /v 8021xEnabled /t REG_DWORD /d 1 /f
You misspelled Services. Might want to correct that in your blog.
Should be:
Reg add “HKEY_LOCAL_MACHINE\SYSTEM\CURRENTControlSet\Services\vmsmp\parameters” /v 8021xEnabled /t REG_DWORD /d 1 /f
Regards
Fixed, thx for pointing that out. Meanwhile, I have this in a POC with contracting devs already. So far so good.
Yep, after the correct reg key it’s working for me as well! Thanks for the work in identifying and testing this solution. It’s a long time coming for Microsoft to join the rest of the community.
Is there any official MS documentation on this? I have been searching and can’t seem to find anything
Not as of yet that I know off. But bar this registry setting this is all RADIUS/NPS/802.1x configuration with the Hyper-V switch as an unmanaged switch in this regards in the mix.
It doesn’t work for me. I added the key but on the virtual switch property I keep seeing just Networking and Sharing tabs
Pingback: Hyper-V und 802.1X – Andy's Blog
The fix doesn’t seem to work if you don’t share the vmswitch with the management OS.
It works fine but if I try to do a PXE boot it doesn’t get DHCP done. Do you know how to get PXE boot and 802.1x working together?
That’s always a challenge but take a look here for great guidance: https://www.asquaredozen.com/2018/07/29/configuring-802-1x-authentication-for-windows-deployment/