Captive portals do cause issues on smartphones and tablets. Users hate having to open up their browser to authenticate before an app can be used.
If you want to invite the devices onto the network, you have to make them usable - over complicating matters unfortunately puts barriers in the way of the original brief. Finding the happy medium is tough.
Radius for us is part of the same ruckus setup that does dpsk that irritable tech mentioned, its reasonably smooth and we have the promise of shiny apps and services staff we can entice them with when they play ball
For those using pre shared keys and saying only IT know the key, you do know there are lots of tools out there that can recover the key once its on a system??? usually the tools require admin rights which all users shouldn't have but with it being there personal device then they will probably have admin rights. so my question is how do you stop this??
To the original question we have a separate SSID with a captive web portal which uses AD for authentication, this puts the users on a separate vlan with ACL's and then our firewall also filters traffic and only allows some ports out.
For email we run exchange 2010, we only allow SSL connections to the server and if the user wants to connect there phone they are required to encrypt there device and setup a passcode.
On a note about personal mobile devices being used to access emails, etc ...
Within your AUP you must point out that these devices must be encrypted, secured with a complex passphrase (4 digit pass code or being able to follow a greasy, sliding trail on the screen is *not* good security) and, where possible, set to autowipe after x failed attempts to log in.
Staff should give permission for routine checks to see that this is in place on personal devices, and should it not be then that device will be blocked from accessing the service.
These are the *reasonable* technical and organisational measures that can be put in place to protect data (DPA principle 7).
If staff don't like the IT staff doing checks then you increase the technical measures (VDI, etc) but the school accepts that this increases the capital and operational costs of the service.
You *do* need it in the AUP as you are keeping staff informed, gaining their acceptance and understanding of how and why things are set up in a particular way. If you don't include things like this you are not helping yourself or the school.You don't even need it in the AUP.
You can set security rules in O365 if they're adding it to mobile devices. [IIRC]
It is not *all* about the technology, but also about the education of users ... oh, and PR too.
This is a very handy post, although working in primary schools with very basic filtering etc makes BYOD much harder to implement. I have noticed remote wipe / policy pushing to devices in the Google apps for Education admin panel but have never played with it, something I will now rectify.
There are currently 1 users browsing this thread. (0 members and 1 guests)