How to keep users BYOD devices off of the Radius SSID?

  • 1
  • Question
  • Updated 1 year ago
  • Answered
I have searched and there may not be a solution but here is my scenario:

1 RADIUS SSID
1 BYOD SSID

I want all users that have a district owned device to connect to radius - iPads, Macbooks, Windows.

I want all BYOD devices to connect the the BYOD network - which is firewalled for internet only access.

So how do I keep a teacher from bringing a personal Macbook from home and connecting to our RADIUS SSID?


Photo of Kevin Martin

Kevin Martin

  • 5 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 1
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The best solution is to use device certificates on your 802.1X-based (RADIUS) SSID.

As far as managed networks go, Microsoft's Active Directory supports secure issuance of device certificates and 802.1X supplicant configuration via Group Policy.
Apple's server can do the equivalent for the clients that it controls.

As far as unmanaged devices go with 802.1X that you may want on this SSID, Cloudpath makes this really easy to do and is, in my opinion, the best available in the market... but it is relatively expensive.
Aerohive have their own enrolment solution too that issues device certificates that may meet your needs.

If you can be so minded, you further use the Calling-Station-ID at the RADIUS server that contains a client's MAC address. That stops somebody casually lifting a client's certificate (public and private keys) and installing it on to another device where they are not well locked down to begin with. (Note that properly locking down the endpoint is the secure way to prevent this, not relying on a MAC address.)

Can I ask why you are running with two SSIDS, is one PSK-based?

Basically, you need to avoid using PEAP with MS-CHAP-v2.

Nick
(Edited)
Photo of Kevin Martin

Kevin Martin

  • 5 Posts
  • 0 Reply Likes
Right now I have 3 SSID's but will eliminate one.  So let me explain that setup.

SECURED-WIFI - Windows laptops w/ group policies 802.1x Radius and district devices such as iPads and Macbooks.

HIDDEN-WIFI - WPA2 password that we hard code into district "student" devices so they don't have to do technically log into anything.  It seemed to be a good idea for elementary students that don't have windows accounts.

GUEST-WIFI - no password firewalled w/ captive portal page for guest access.


You got me nervous now - all the MS documents say to set up NPS/Radius using PEAP with MS-CHAP-v2.



Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Kevin,

Just a quick point of clarification...

You can and should, of course, always check for group membership of a computer or a user.

What you cannot do with EAP-PEAP or EAP-TLS is base a conditional check on two credentials, only ever one is supported.

With device or user certificates, a unique credential can be issuesd on a per-device or per-user basis on an is needed basis. Through proper endpoint lockdown, you can ensure that they cannot be lifted. The belt and braces check, although it is fundementally not a secure mechanism, is use the device's MAC address too when authentication takes place.

Watch the videos from the link above for some good coverage of the issues.

Nick
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
Which, of course, is not what the NPS policy says; it indicates that the user groups concern a user and the machine groups concern a computer. I did test it though, and got the results of "it doesn't work." All is...well?
Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
The NPS docs are correct actually. User groups do concern a user, but if the credential mapped to a device/machine the check is always meaningless/invalid.
Photo of J. Goodnough

J. Goodnough, Champ

  • 266 Posts
  • 32 Reply Likes
A couple more tests and I get what's going on, thanks for the explanation. Again, not particularly intuitive with the interface given, but makes more sense when you know the details of the credential situation.
Photo of Kevin Martin

Kevin Martin

  • 5 Posts
  • 0 Reply Likes
SO the long of the short is that Windows NPS cannot do a both "AND" statement of this user AND this machine = successful login.

I was under the impression that the device needed to authenticate "pre user login" so that when the user was at the login screen then they could login.  This is the whole reason why we did RADIUS on the windows machines.

So I am guessing this is now inaccurate.  The device registers with a certificate and that has nothing to do with the certificate.  So technically I can remove the user groups from NPS and my windows machines will still be able to connect (but it will break an iPad/Macbook from connecting)?

Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
Nothing to do with NPS, this is something intrinsic to the authentication mechanisms we use (EAP types). It is an intrinsic limitation of the clients (supplicants) too.

What you are talking about uses independent credentials provided to start independent connections, they are entirely unrelated. There, you have a connection using machine/device credentials that is first established so a user can login interactively and then an entirely new connection is established with the user's credentials as they log in.

Think about the implications that flow from this...

To get this right, you therefore have to use a certificate for the user and not their username and password. Conceptually, their certificate must be one is only securely/dynamically distributed to and used by your district managed devices. Practically, this is not really possible.

(Edited)
Photo of Ruchi Sharma

Ruchi Sharma, Employee

  • 2 Posts
  • 0 Reply Likes
Another feature that can be used to redirect personal devices off of the RADIUS SSID/VLAN is using "Client classification". Client classification can be set Under User profiles-> Client classification.
What it essentially does is identify devices by the OS - so Windows phones, Iphones and Android devices can be identified and forced to a user profile of "Guest" or Byod user profiles. This occurs on the back end - so on the surface the Employee will connect to the main SSID, but will receive an IP address from the BYOD subnet, and be subject to the BYOD User policy.



Photo of Nick Lowe

Nick Lowe, Official Rep

  • 2491 Posts
  • 451 Reply Likes
A big thing to keep in mind here is that this is not a secure mechanism. It is on par with deciding access based on a MAC address. This is why I do not recommend this. However, it is convenient!
(Edited)
Photo of Joep van den Heuvel

Joep van den Heuvel

  • 8 Posts
  • 1 Reply Like
What I tested today, is that Client Classification does not work when u use Radius as the authentication mechanism. If I do so, and it doesn't matter what classification rules I try... the clients authenticates by Radius, and is placed in the default profile (which belongs to the SSID). So to clarify my bad English:

I made an client classification rule which you can see below:


With this rule, all Windows computers use the default profile.
All other use another VLAN profile for 'BYOD'

I Login with my Iphone and, it connects to the default profile, not to the BYOD (vlan254).

I removed the windows rule, so any any any will connect to VLAN254 but it still doesn't work.

Contacting my re-seller, informed me that using radius, will overrule the classification policy, because the radius attributes enforce the vlan etc.. (but I'm not using an attribute which forces the client to an specific VLAN ID)... 

Anyone got an Idea?
Photo of Roohulla Neri

Roohulla Neri

  • 1 Post
  • 0 Reply Likes
Hi Guys,

We have a windows radius server for single sing on authentication, it's was working fine, But we need to block mobile device ( ios and android devices). how should i block ?