Higher Education

I've been tasked with coming up with a new design for our dorms to help the students have a more "at home" experience. While I have what I think are some great ideas, others thought that it was too cumbersome....

 

I'm curious, what are other Universities doing for their residential colleges (dorms) for the students, to allow them to connect their IoT devices? (Apple TVs, Rokus, Fire TVs, Sonos, Echos, Google Homes, Kindles, just to name a few)

 

 

My idea:

1 network

      - mac auth + PSK

      - We currently have airgroups enabled but I'd like for the students to be able to use clearpass to segregate their devices from eachother

      - PSK changing every year, and database getting wiped every year

1 network

      - open (or PSK from front desk); ideally for the "Guests" to the dorms (parents, other students, friends from around)

      - PSK changing every semester

 

 

I do realize its sort of chicken & the egg with the mac-auth...I'll figure out something for that later :-D

 

 

Thanks in Advance!

Generally, we recommend a dual network setup.


1. 802.1X network for primary usage
2. Open network with MAC authentication for guests and headless devices

One more thing to consider, going forward, is how WPA3 features will play into this environment.  WPA3 wil make PSK and open(ish) networks a bit more safe from the crypto standpoint.  Spoofing-wise, WPA3 headless devices will also be able to do dot1x through remote confiuration APIs, but of course you'll always have older WPA2 devices kicking around as well.

 

Not exactly correct. WPA3 does not give devices without an 802.1X supplicant the ability to all of a sudden do 802.1X.

Of course... my point is that some device classes that previously never used dot1x will have among their ranks some dot1x capable clients.  So plan accordingly.

 

Timing of this is great, as we’re also looking at augmenting what we have. Today, we have primary 802.1X SSID and we have an Open/Captive Portal SSID with a click-through guest login. The same Open SSID does MAC auth as well for pre-registered devices. All the roles that are derived block unestablished inbound connections, which breaks many of the headless devices, so we’re looking at making modifications.

One idea I had was to modify the self-registration for devices to include a checkbox or sorts where the person would opt-in to allowing inbound connectivity. There’s a ton of risk associated with that obviously, but I’m not interested in creating roles for every device type.

I’m very interested in hearing others’ ideas in this regard… not just for dorms but for higher ed in general. I’m sure your faculty are wanting similar things, too!

- Ryan -

You can use ClearPass roles during device registration which would allow the user to select the device type and you could map them back to controller roles.

Yeah, I realize that that’s technically possible. But my concerns are to scale. Building something to capture specific device types will require a lot of ongoing maintenance, so common denominators are desirable.

I appreciate the feedback, Tim, though I’m more interested in what other customers are doing. If you have those insights, I’m all ears!

I usually recommend high level groupings like “Media Player”, “Printer” and “Game Console” which reduces the long-term maintenance.

Ryan, What did your group finally decide on with the Dorms?

Other projects had taken precedence over this, but we’re reenergizing things after ATM19 finishes out. I’ve had a lot of in-depth conversation with Aruba regarding CPPM AirGroup policy in combination with the AOS autoassociate functionality. Once that flushes out, we’ll come up with a plan and I’ll try to remember to post what we do here. If you don’t hear from me, feel free to poke. ☺

- Ryan -

We have a specific open SSID for headless devices.  We hide the SSID and have it locked down in Clearpass so that only devices that are registered in Clearpass Guest are allowed onto the network.  In addition to the forced registration of devices rather than having an allow rule for specific device types we block certian devices such as smartdevices and computers.  That effectively forces all the devices on that network to be headless devices.  When the device is registered in Clearpass Guest the only role allowed (for the customer) is a registered device which we have set as the default.  We have specific roles in our controllers for that SSID as well as having it segregated onto its own separate vlan.  We do have airgroup enabled in our network.  

 

The one major hiccup that we have run into is that all Amazon devices register as a Kindle Fire.  The Fire is considered a smart device.  This causes problems for the Amazon Echo.  There are pre-built categories in Clearpass for the echo but the device profiling doesn't seem to work and as far as we have been able to tell it is a limitation on the Amazon side of things rather than Clearpass.

---

@Hephzibah11wrote:

We have a specific open SSID for headless devices.  We hide the SSID and have it locked down in Clearpass so that only devices that are registered in Clearpass Guest are allowed onto the network.  In addition to the forced registration of devices rather than having an allow rule for specific device types we block certian devices such as smartdevices and computers.  That effectively forces all the devices on that network to be headless devices.  When the device is registered in Clearpass Guest the only role allowed (for the customer) is a registered device which we have set as the default.  We have specific roles in our controllers for that SSID as well as having it segregated onto its own separate vlan.  We do have airgroup enabled in our network.  

 

The one major hiccup that we have run into is that all Amazon devices register as a Kindle Fire.  The Fire is considered a smart device.  This causes problems for the Amazon Echo.  There are pre-built categories in Clearpass for the echo but the device profiling doesn't seem to work and as far as we have been able to tell it is a limitation on the Amazon side of things rather than Clearpass.

---

We have not yet enabled the DHCP part of device profiling for ClearPass so we currently do not use Profiles. 

Have you opened a TAC case to see if Amazon Echo can be differentiated from the Kindle Fire? The Kindle e-reader should also be profiled differently.

We have not seen any Kindle e-readers that seem to have problems.  We do not currently have one to test with so I am not sure if it will profile as a kindle fire or a kindle e-reader.  The profiling rule is not set up specifically as a fire it is as a Amazon->Kindle.  The kindle falls into the "smartdevice" category.  It is a simple change to put it into the home audio/video category and set it as either an echo or a fire tv.  We have not opened a TAC case as it has not been a high-priority issue as of yet.  As far as we can tell the kindle fire, the echo, and the fire tv all run slightly different versions of fire os and that is why they all profile in the same category of device.

Would you be willing to share some of this with me offline? I am working with Aruba support and believe we got most of it done but you raised some questions I would be interested in.

---

dmattox@millsaps.eduwrote:
Would you be willing to share some of this with me offline? I am working with Aruba support and believe we got most of it done but you raised some questions I would be interested in.

---

I would be more than happy to.  Sent you a DM

@Hephzibah11 wrote:

 

The one major hiccup that we have run into is that all Amazon devices register as a Kindle Fire.  The Fire is considered a smart device.  This causes problems for the Amazon Echo.  There are pre-built categories in Clearpass for the echo but the device profiling doesn't seem to work and as far as we have been able to tell it is a limitation on the Amazon side of things rather than Clearpass.

---

We just let anyting that fingerprints as "Kindle" onto the network.  No point letting the perfect be the enemy of the good.  Nobody's died yet.

We have two SSID's in our dorm and broadcast both. One is 802.1x and the other is open for non 802.1x devices. Our open network uses mac registration through clearpass and all 802.1x devices that hit our open SSID get hit with a not allowed splash page from clearpass. We have run into a new issue with some devices now in 2020. I am going to start a new post.

We have our users register the mac address of non-802.1X devices in a web portal. This summer we are moving to a small choice of devices types, 3 of which are configured as AirGroup servers.

 

Registered Device

Apple TV

Chromecast

Other AirGroup Device

 

The default option is Registered Device, rather than forcing a choice.

 

Later on we plan on moving from our 3 current main SSIDs (802.1X, Guest, MAC Auth/Onboarding) to just 2, combining Guest with the MAC Auth/Onboarding SSID.

Wow! Seems like most of you are doing .1x in the dorms as well. Are all the devices falling to the same vlan? headless & .1x?  Our main issue is the Chrome/google casting that the students want, as they fall into 2 separate vlans, and it seems like with every update of an app or Chromecast, something breaks.

 

I currently have the main SSID on .1x for the students, and require them to register their headless devices in clearpass, but have so many issues with these extra devices and the home-functionality that the students want to have.  Hence the request to make it "more like home" for them. Of course, when they go to their classrooms, they're back on the .1x SSID.

What we found is that after enabling Airgroup if the user enables guest mode they should be able to see and use both google home/chromecast devices without issue.  As I mentioned previously we have our "entertainment device" netowrk setup as completely open with the only security being through clearpass, segregated vlan, and hidden network.  Students phones, laptops, etc are still on the .1x vlan and the headless devicecs are on a open network segregated by vlan that has registration required through clearpass guest.  We have seen a few google devices that need to be re-profiled as chromecast but those are few and seemingly far between