Windows 10 bypass 802.1x certificate validation

  • 1
  • Question
  • Updated 2 years ago
We setup 802.1x on our network, originally with windows 7 devices. We used the default Hivemanager cert and loaded it on all the machines. With windows 7, if you didn't have the cert installed, you couldn't connect unless you manually unchecked "verify certificate". It appears in Windows 10, you can just connect to the SSID and it allows you to bypass the cert validation without any necessary configuration. How is everyone handling BYOD with Windows 10 devices? I know this could have been an issue with Windows 7, but at least there was the necessary know-how of creating the profile and finding that "verify certificate" check box. Now you don't even need to do that. 
Photo of weardj

weardj

  • 4 Posts
  • 0 Reply Likes

Posted 2 years ago

  • 1
Photo of Deven Ducommun

Deven Ducommun, Beta Program Manager

  • 53 Posts
  • 5 Reply Likes
Hi weardj,

I'm confused by the issue here. What is the end goal for those windows 10 devices?  Do you not want them connecting to your SSID at all or do you want them pushed into a BYOD profile? It sounds like there are a couple possible solutions but I want to be clear in what the desired result for these devices is.  

Thanks,

Deven
Photo of weardj

weardj

  • 4 Posts
  • 0 Reply Likes
We used to be able to prevent BYOD Windows device from connecting because the certificate couldn't be validated. Most users didn't know how to avoid that by unchecking the box. I want only corporate devices to connect to the SSID, or at least push everything not corporate to a Guest profile. How can you do that with mixed BYOD and corporate Windows machines? MAC filtering the only way?
Photo of Deven Ducommun

Deven Ducommun, Beta Program Manager

  • 53 Posts
  • 5 Reply Likes
Well if you do not have any corporate owned Windows 10 machines you can create a custom OS detection object for windows 10 and use that to put those machines into a user profile on a different VLAN than your corporate network.  Doing a whitelist for all corporate devices with a redirect policy for any device not corporately owned to the BYOD profile is something that can be done.  Alternatively if you do install root CA certs on your windows machines you can instead install client certs and do TLS authentication which would be the most secure solution but also the most administrative overhead.    
Photo of weardj

weardj

  • 4 Posts
  • 0 Reply Likes
Thanks, unfortunately we have a mix. Know of good walkthroughs for setting up TLS?
Photo of Tash Hepting

Tash Hepting

  • 55 Posts
  • 29 Reply Likes


They switched around how it works, but you can still get the same results. The main thing is that by default they allow the user to accept the certificate when connecting and then warn if it changes.

Details on how to use the new settings are here: http://www.windowsnetworking.com/arti...

Cheers,
Tash
Photo of weardj

weardj

  • 4 Posts
  • 0 Reply Likes
That stinks. Any way of preventing non corporate devices from being able to connect, or at lease force them to a Guest user profile?
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
The validation of the RADIUS server certificate by the client is something that the client can use to verify it is talking to the RADIUS server it expects, but as you note, as this is completely in the control of the client, it doesn't provide any real security benefit for your network - what it does is provide protection for the client from connecting to a "spoofed" SSID.

Most mobile operating systems will quite happily talk to a RADIUS server that is using an untrusted SSL certificate by default and as you note, some desktop operating systems now do the same in the interests of "convenience" for users, which is - unfortunately - viewed as more important these days in a lot of circles.

The most robust solution, as has been suggested already, is to switch to using EAP-TLS or PEAP-EAP-TLS (computer or user certificate authentication) rather than PEAP-EAP-MSCHAPv2 (username/password authentication). This will require you to set up a certificate infrastructure and use auto-enrolment and group policy to administratively control what the clients can do. If you have Mac clients, you can achieve the same using the features of OS X server or an MDM solution to enrol for certificates and push out settings.

If you use PEAP-EAP-MSCHAPv2, you basically have no way of controlling which devices are able to connect - if they know the username and password, they can connect. With certificate authentication, you are ensuring that the client has to have a valid certificate and key issued by your certificate authority - once you lock down the access to your certificate authority (so users can't easily manually enrol for certificates) and mark the private key as non-exportable, you make it much harder for non-corporate devices to connect to the network. It's not 100% perfect - you can go further and implement other solutions on top (MDM, VPN) but this obviously costs money and can introduce new problems for users. Security vs. convenience again.

The other thing about pushing out the wireless settings administratively is that it provides protection against somebody spoofing your SSID and attracting clients to connect, as you can specify in the SSID settings that are pushed to clients that they should check the certificate provided by the RADIUS server has the right subject and is signed by the right CA, and these settings cannot be overridden by the user.