Managing BYOD for secondary school

[genesis]

Hi

 

We are a secondary school with 800 students. We are using Ruckus wireless system and now the senior management wants to issue Wi-Fi passwords to the students.

Means the students may bring their own device such as iPad, mobile phones, tablets or laptop to connect to the school Wi-Fi.

 

Is it a good idea to setup one SSID with restricted access and provide the password to all the students?

Do I need to have inventory of every device of the student to have control over them?

How do you manage in your schools and Please let me know the best way to implement this set up?

 

Any help would be great.

 

Thanks in advance

[Rob_D]

We don't run BYOD (yet), but have set up staff and student SSIDs (mostly for web filtering). Then we've got radius setup so they can authenticate with their network credentials. You can control access through AD group memberships. (We have a wifi group that people need to be in to be able to authenticate).

 

It might also be worth having a provisioning SSID. No authentication, but only takes them to a portal where they can download the necessary certs and management profiles/apps.

[colly72]

We've had a BYOD policy for the last 2-3 years, using a Meraki wifi network. We have a segmented VLAN, which we use to split the BYOD devices from the network, with isolation enabled so they can't see any other devices. They authenticate with our Sophos UTM using browser authentication, then we filter/scan as we do on our LAN It works really well but.......

 

My advice would be to avoid BYOD. We've found that it's very difficult to monitor and control what the students are accessing on their own devices. From a pastoral/safeguarding viewpoint, it's a problem. It's also difficult to have consistency, with students using a combination of devices. We're now looking at school-provided Chromebooks that we control, to prevent these types of problems.

 

Best of luck if you do go ahead with it.

[AlanD]

I would use enterprise WPA for login, with a radius set that authenticates from a AD server using their normal login credentials. That means there is no further login challenges for filtering, and usually once students enter the data in their device it remembers it forever.

 

There are schools that ban BYOD, but the reality is that students even in these schools are making regular use of their phones, beneath desks and behind books and toilets become an Internet cafe. With data packages of 20GB, 100GB or more for less than £20 per month they don’t even need to use a WiFi. And in any case most schools are completely unaware that clever students are able to crack WPA2 SSID passwords quite easily with free online tools.

 

And staff rarely even hide the fact they are using Facebook during lessons...

 

My philosophy is to embrace BYOD. Encourage them to use WIFi and at least monitor their use as well as possible. There are loads of good apps that can be used...and perversely students hate it when they discover that you are going to make them use their devices for something useful in the lesson.

 

Students have always passed notes, and blown them in biro shells across the classroom. Using devices, is just the modern way. Pick up a device on the pretext that something is amiss and embarrass them by drawing attention to some Instagram message you find...that usually makes them pretty wary not to have inappropriate messages when they know you are likely to do this,

[NotwerkManager]

My instinct is to avoid BYOD due to being unable to verify whether a unit is 'safe'. You get one genius with something particularly nasty which wipes out a load of kids' devices, and suddenly it's all "our fault" because they were on our network at the time. I do accept that it's the way things are going though, and therefore it's our problem to solve now.

 

Where I am, we currently manage BYOD through use of 4-hour guest passes on the WiFi (generated in bulk and printed off for issue), keeping pretty strict filters on Smoothwall, and hiving it all away from the main network on a separate VLAN.

Edited March 9, 2019 by NotwerkManager

[smarties11]

My instinct is to avoid BYOD due to being unable to verify whether a unit is 'safe'. You get one genius with something particularly nasty which wipes out a load of kids' devices, and suddenly it's all "our fault" because they were on our network at the time. I do accept that it's the way things are going though, and therefore it's our problem to solve now.

 

Where I am, we currently manage BYOD through use of 4-hour guest passes on the WiFi (generated in bulk and printed off for issue), keeping pretty strict filters on Smoothwall, and hiving it all away from the main network on a separate VLAN.

 

This situation is entirely avoidable. All the best enterprise Wi-Fi APs and controllers have the ability to enable device segregation which means client devices can't see each other. Plus most controllers will allow you to filter traffic so clients can only talk to your proxy and any other IP you specify. Best to embrace BYOD; at least on your network your students browsing is logged. We've used device segregation for the last 7 or 8 years of offering BYOD and we've never had anything spread between devices; it's impossible for it to happen!

[NotwerkManager]

That's great. It may even be something that we've got in place already - I'll have to check. It's something I've always wanted to get more involved in, but it's not fallen under my remit until this week - so I've got a lot to catch up on!

[DrBeaker]

Has you got a safeguarding lead in school at all?

 

Would be interesting to hear their opinion on this for classroom management, cyber-bullying etc?

[NotwerkManager]

We do. We had a bit of a chat on Friday. I know we currently have all of the Smoothwall reporting and any email from or to student accounts which contains potentially inflammatory words gets forwarded to ICT for assessment and reporting through CPOMS if appropriate. I've not yet tested to see what happens if something pops up on the guest access and how easy/hard it is to identify. I've already identified that nobody seems to track which WiFi guest logons are given to who, but I can chuck together a simple procedure to rectify that.

[AlanD]

I've already identified that nobody seems to track which WiFi guest logons are given to who, but I can chuck together a simple procedure to rectify that.

 

I wouldn’t have more than one guest login SSID .and you capertainly don’t want any more SSIDs than absolutely necessary, because simply advertising their own presence consumes a disproportionate amount of WiFi bandwidth.

 

In fact...the best solution by far might be a single SSID...and allocate AD usernames to guests...

 

Use VLANs to make sure that a guest login doesn’t get to access any of your protected resources like servers.

 

Guests...should be guests...not staff...who should get proper logins...and yes, their activity would be subject to monitoring. Note...that schools are required to monitor...and report...as well as filter. Over filtering can lead to a lack of monitoring.

[Tefters]

Secondary school here with 1400 students.

 

Personal advise is to avoid BYOD as it’s a huge safeguarding issue to the school but as we all know SLT don’t listen so here’s my setup.

 

Student WiFi is for sixth formers only, they are considered mature students and requires a consent form to be signed by both parent and student accepting fair use and that we do all we can to protect the students online however anything we deem unreasonable results in a block, no second chances!

 

It’s an SSID with radius setup against an AD group which we add students to after signing and handing over the form, this authentication is between the AP’s and radius not by filtering and radius!

The SSID is completely VLAN’d off and can not touch internal resources.

The gateway for this VLAN is an interface on our Smoothwall then out to the Web, the wireless itself is Meraki.

 

We tried an open SSID which then needs authentication through a caption portal on the filtering however this resulted in Onion Browsers (anonymous browsers) being able to circumvent this so authentication got moved direct to AP’s for access to the SSID itself.

 

The students filtering on the BYOD is exactly the same as if they were on a school pc except we allow more ports as it’s their own kit.

 

Meraki can show us breakdowns in traffic and which devices are logged on with which logon and we always have 2 issues consistently:

 

1. Multiple devices with the same logon = If it’s more than 2 or 3 then we insta-block the MAC’s of the devices with a message to see IT Support. The kids come, we quiz them, they cave in and admit sharing logons and we then congratulate them on being insta-banned with no second chance. They signed the form after all and so did the parents. Meraki also shows type of device and which AP it’s connected to at the time so makes this real easy...

2. Meraki shows data type/usage and we see 90%+ UDP miscellaneous traffic = Students using a VPN to circumvent filtering, insta-ban on MAC and removed from wireless group with a note on their AD account. Some of them come to plead they didn’t know and have no clue what a VPN is so we ask to see the device and both Apple/Android leave profiles in network security even after deleting the VPN app the student was using and then deleted. We also ask them to show us their store apps which shows they’ve been downloaded.

 

I feel like we’ve nailed BYOD from a student perspective here and only got it for sixth formers who the majority shoot themselves in the foot and lose the access later one way or another...

 

EDIT - Forgot to add that in the small print of the consent letter is a small get out of jail free clause for us should a student use a VPN for a few days and surf inappropriate content (porn) and show it around and we don’t notice.

We check the Meraki portal once a week or every other so the bans are in waves but the letters do cover us from said parent shouting the odds.

Edited March 9, 2019 by Tefters

[Prevention]

Radius is really the only way to do it to be honest.

That way you can capture MAC Address against Radius Auth.

[chazzy2501]

If I were FORCED to allow a BYOD I'd insist on a Meraki Solution, not only can you isolate guest traffic at the AP but each AP can NAT, or and this is the big one... it can setup a VPN between the AP and the firewall. This ensuring that guest traffic can't hop a vlan and extricate other network data.

 

Belt and braces I know but this is how I'd do it.

[PlantHead]

We have Ruckus and BYOD policy.

 

Setup Radius for authentication and then forward all accounting information to your firewall so you can report on it and track potential VPNs, which are always a problem.

We have 1 pupil SSID, with client isolation switched on.

Deep packet inspection is the big problem - getting certificates onto each BYOD device is a real pain. We have a webpage handed out from our firewall for BYOD devices but it is far from a perfect solution.

 

I would like to force intune or similar onto each client that attaches to our network but that is quite a step for the school to get its head around.

Edited March 11, 2019 by PlantHead

[Rob_D]

I would like to force intune or similar onto each client that attaches to our network but that is quite a step for the school to get its head around.

 

This is the main stumbling block we're coming up against. Like you, we'd like the devices to be managed/monitored while their being used in school on our network. But we really don't want to have any management/monitoring while their at home.

[chris11256]

From our perspective, we have a WPA2 Enterprise BYOD network which all pupils/staff can connect to with their AD credentials. It's a Cisco solution with a 5508 controller and a mixture of Cisco access points.

 

We're not in the business of managing their personal devices, but our firewall alerts us if a specific device is accessing something that they'd only access if they were infected. The BYOD network has no access to other internal resources, only Planet Estream, our intranet page and Papercut mobile printing service. The same web filtering applies to users regardless of method of access(firewall does it on Staff/Pupil basis rather than origin device). Although we do SSL Decryption on domain pcs, we're not doing it for BYOD devices.

 

Works quite well for us. We have the view that we'd rather they use our resources and if things are too restrictive, they'll just switch to 4G which we have no control over,

Edited March 11, 2019 by chris11256