Can I reject non-company clients from a 802.11x SSID?

  • 1
  • Question
  • Updated 3 years ago
  • Answered
Or better yet, only allow company-laptops to connect?

We have successfully setup an 802.11x SSID for company-laptops. This network is working great but the company users are now discovering that they can connect using their iPads as well.

They can simply select the SSID from the list, supply their valid AD credentials and connect. The iPad doesn't trust the certificate of the RADIUS, but iOs allows the user to accept the certificate via a prompt.

Using this SSID they have access to resources we would like to shield from iOS devices.

What are our options? Or am I stuck with MAC filtering?
Photo of Jornt Weyts

Jornt Weyts

  • 26 Posts
  • 3 Reply Likes

Posted 5 years ago

  • 1
Photo of Brian Powers

Brian Powers, Champ

  • 396 Posts
  • 92 Reply Likes
One way to possibly accomplish this would be to do Machine Based authentication as opposed to user based. Instead of creating a group of domain users that have rights to access this SSID w/.1X authentication, you can create a group of computers that are on your domain.

MAC filtering is a possibility, but as MAC's can easily be spoofed, and the clients know a "good" MAC (their laptop/company machine), with any knowledge they can easily bypass this security.
Photo of Jornt Weyts

Jornt Weyts

  • 26 Posts
  • 3 Reply Likes
How would I go about and configure machine based authentication? Any reference material available?
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
The standard practice is to use 802.1X machine authentication followed by user authentication and there are lots of articles on the Internet on how to do this.

So I thought I would go through some of the cool ways you can handle Android and iOS devices with the Aerohive solution.

When a wireless client connects to a WLAN it will generally send out a DHCP Request to get an IP address. We can use the information inside the wireless client's DHCP Request to identify the operating system of the wireless client using DHCP's option 55. To enable this under the 5.1r5 HiveManager click Configuration -> Advanced Configuration -> Management Services -> Management Options and under the Service Control section you will see the "Enable OS Detection Methods" options. They are:

* Use DHCP option 55 contents - use the wireless client's DHCP Request information to determine the wireless client's operating system

* Use HTTP user agent IDs - use the wireless client's HTTP traffic to determine the wireless client's operating system.

I have had issues with the HTTP user agent on iOS devices and, if the user doesn't access the Internet using HTTP, you will not be able to identify the operating system. Therefore I recommend you enable the "Use DHCP option 55" option.

* Use both detection methods (DHCP=primary method, HTTP=secondary method) - Use DHCP then HTTP detection to determine the wireless client's operating system.

We are now going to use client classification policies to give non-domain devices with valid domain user credentials Internet access only - a basic BYOD solution.

Go to the User Profiles area (Configuration -> User Profiles) and create a new user profile that only allows Internet access and call it "Internet_Only".

Open the user profile that your 802.1X authentication process matches wireless clients into, expand the "Client Classification Policy" menu and enable the "Enable user profile reassignment based on client classification rules" option.

In the "Policy Rules" table that appears click on the "OS Object" drop down menu and select "iPod/iPhone/iPad". Click on the "Reassigned User Profile" drop down menu and select the "Internet_Only" user profile you created earlier. Finally click on the "Apply" button.

You have now created a rule so any iPod, iPhone or iPad that is matched into the 802.1X user profile is automatically reassigned to the "Internet_Only" user profile and only gets Internet access. Remember that for the wireless client to be assigned to the 802.1X user profile the user must have entered a valid domain user credential or their association would have been dropped by the 802.1X process.

To redirect OS X and Android devices repeat creating the same rule for the MacOS and Android OS objects and only Windows clients will not be redirected to the "Internet_Only" user profile.

We now want non-domain Windows clients redirected to the "Internet_Only" user profile so click on the "New" button, click on the "OS Object" drop down menu and select "Windows". Click on the "Device Domain Object" drop down menu and select "Unknown". This rule will match Windows wireless clients that are unknown to the domain - i.e. they are not domain clients. Finally click on the "Reassigned User Profile" drop down menu, select the "Internet_Only" user profile and click on the "Apply" button.

Now the only device that can remain in the 802.1X user profile is a domain Windows device. All other devices will be redirected to the "Internet_Only" user profile.
Photo of Mike Kouri

Mike Kouri, Official Rep

  • 1030 Posts
  • 271 Reply Likes
Crowdie, I've been very impressed with the completeness and accuracy of your answers. Good job!!
Photo of Jornt Weyts

Jornt Weyts

  • 26 Posts
  • 3 Reply Likes
Thanks Crowdie,
I've tried the proposed setup and it is working as expected. I'm confident that this configuration will suit our needs.
Photo of Jornt Weyts

Jornt Weyts

  • 26 Posts
  • 3 Reply Likes
A followup question:
Can I use "Unknown" in the 'Device Domain Object' in combination with Mac OS? If I would join a Powerbook to the domain will I get the same behavior as a windows machine.
My first test appear to say: no
Photo of Jornt Weyts

Jornt Weyts

  • 26 Posts
  • 3 Reply Likes
After some additional testing it became clear to me that this setup doesn't actually check if the PC has joined the domain. It just tries to grab a domain name from the username used to logon.

Initially this setup seemed to work just fine because joined PCs automatically add the domain name, and PCs in a workgroup do not.

But if I were to add the domain name to the credentials, I can log on using 802.1X Authentication on any windows machine and still get assigned the userpolicy meant for Company PC's (Windows or Mac OS)

So while this setup is great if you want to reject (= reassign) an entire OS, like iPad or Android, It doesn't really ensure that only company PCs can use the SSID.
Photo of Dominic Kirby

Dominic Kirby

  • 1 Post
  • 0 Reply Likes
This is a pretty old forum, but just wanted to throw out there that we use Machine based authentication in our shop, and also have a very limited subset of users (execs, it admins etc...) that can authenticate against their AD login.
Photo of Joep van den Heuvel

Joep van den Heuvel

  • 8 Posts
  • 1 Reply Like
I Don't understand why I can't get this to work. 
Enabled the identification (was enabled by default)
enabled client classification, but whatever I try, My Iphone enters the default VLAN instead of the one in the client classification policy.

See for a full comment my reaction in this post:
https://community.aerohive.com/aerohive/topics/how_to_keep_users_byod_devices_off_of_the_radius_ssid


I even tried adding my complete MAC address (in red) in the Client classification.. but it just connects to the default VLAN / profile associated to this SSID:
(Edited)
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
Rather than using client classification policies why don't you:

  • Create a single WPA2 Enterprise SSID
  •  In the NPS RADIUS server (or equivalent) create a connection request policy allowing PEAP MSCHAPv2 authentication and two network policies.  The first will match the device against an AD machine group (either a newly created security group or Domain Computers) and return the domain device user profile attribute.  The second will match the user against an AD user group (either a newly created security group of Domain Users) and return the BYOD user profile attribute.
  • Create a GPO that configures the domain devices to authenticate to the WPA2 Enterprise SSID but only using computer authentication.
  • Connect all the domain devices to the LAN via an Ethernet connection and reboot them.  This applies the newly created GPO.
When a domain device is powered on it will send its hostname and the first RADIUS network policy will return the domain device user profile attribute to the wireless network.  As the wireless GPO only sends computer credentials the wireless authentication is now complete.  When the user enters their domain credentials the domain will handle the user level permissions.

When a BYOD device associates to the WPA2 Enterprise SSID it will not send computer credentials (Android/iOS or workgroup Windows) or send invalid domain credentials (a domain device from another domain).  Either way the computer authentication will not occur so the device will not be matched as a domain device.  The BYOD device should, however, send user credentials and, if these are valid, the second RADIUS network policy will return the BYOD user profile attribute to the wireless network.

A simple, if not exactly perfect, solution. 
Photo of Crowdie

Crowdie, Champ

  • 972 Posts
  • 272 Reply Likes
If you are using client classifiers with iOS devices you will also need to add support for iOS 9 as per https://community.aerohive.com/aerohive/topics/ios-9-breaks-client-classification.