Smoothwall browser on iPads

[synaesthesia]

Sorry, properly spamming the Smoothwall queries at the moment!

Prepare to groan - shared iPads.

Have a small number of them and very little intention of getting more! All we need is to be able to filter & monitor as per KCSIE, ideally either by forcing SSL login page (irritatingly difficult thanks to our trust's SSID setup) or if it's possible to have Smoothwall Browser prompt for it? I can see the setup for this with MDM but the documentation from Smoothwall is diabolical ( https://kb.smoothwall.com/hc/en-us/articles/4404006049810-Install-Smoothwall-Browser-on-iPadOS-and-iOS-devices ) - here's a list, we'll not tell you what to do with it or where the fields need actually entering. And I suspect this is only for shared ipad mode anyway - something I want to avoid if students need to sign in with yet another account (icloud).

Anyone have this working in a usable and compliant manner?

[mjhardisty]

Are you using on-prem or Cloud Filter?

[synaesthesia]

We have both

[mjhardisty]

OK, so you want the iPads to use one or the other and not both then.

 

If your iPads stay on prem, then they won't need the Smoothwall Browser, they can use any browser and configure those to redirect to the Smoothwall On-Prem SSL Login page. The issue with that is that they'll retain the login from the previous user unless configured to used Shared Device.

 

Otherwise install the Smoothwall Browser, configure it with your MDM to use the UserID string. In our Cloud-First setup we have the UserID string as device_serial@schooemailaddress. Smoothwall will use the UserID string for policy access/reporting.

You can then make sure the on-prem policies allow for those iPad users (a user for each serial number) to access the internet. 

 

If that makes sense?
 

[synaesthesia]

Pretty much yeah cheers - I haven't had any luck with the MDM part due to the documentation re the PLIST (Mosyle for the MDM, the client just keeps saying incorrect configuration  ). The smoothwall docs refer to a github page which is absolutely no help at all, no idea what to do with it or if it's even needed.

I think for now we might go down the SSL route, just needs another SSID setting up for us to achieve that but not a major problem - only thing as you say is the timeout, I was hoping that was vaguely configurable.

[tom_newton]

Are you mosyle free or paid?

Proper "shared ipad" per apple's definition?

[synaesthesia]

Free, for the very few devices we have we're avoiding paying for anything. I'm not sure on the shared bit, I don't quite understand how it works as I think you need to sync up with apple to make students an icloud account they sign in with, which I don't want to do.

[tom_newton]

It's always been tricky with Mosyle free - I dont think it works super well. 

You really do need to have students logging in to the ipads properly to use the browser app.

If it's non-logged-in ipads you might be better with the login page

[mjhardisty]

Try this config in the .plist for the Smoothwall Browser application in Mosyle before you try the Shared Mode.

 

<dict>

<key>SmoothwallSerialNumber</key>

<string>SmoothwallSerial</string>

<key>UserID</key>

<string>%SerialNumber%@youremaildomain</string>

<key>HomePageURL</key>

<string>https://www.google.com</string>

</dict>

 

See if that works?

 

In the Smoothwall Cloud Filter you should then see alerts for a user of the devices serial number in the log?

You can then create the according user in AD/Entra and then map it to the appropriate policies/reporting in Smoothwall.

 

As least when responding to alerts then you'll know the specific iPad in question. For individual users it'll have to be Shared Mode. 

 

[synaesthesia]

Thank you for that @mjhardisty - that did work, my problem was putting in the UT hardware serial of our smoothwall instead of the UNCL software serial (there's too many serials and codes!)

So as proof of concept that works with the device name coming through for reporting - it's a slightly less cumbersome method of managing them manually but still not fully kcsie compliant. Manageable for a few devices as long as the staff know who has them and when, but it looks like I might need to tinker with shared ipads or forcing an SSL login page - and that's a struggle as I'm limited as to the VLANS/subnets I can use thanks to a larger trust network template/structure.

[tom_newton]

Shared ipads would be the route id take, rather than the cumbersome login page

[mjhardisty]

I agree with Tom, shared iPads would be the best route, plus it then would ensure the previous user signs out - rather than leaving an iPad on a single session with an authenticated firewall token from previous users. 

Device serial might also work if you have 1:1 devices. 

KCSIE still says "where possible" for identifying the individual on the device, and its exceptionally difficult on tablets.

At least it does allow you to individually identify the device and time using that method.

[synaesthesia]

18 minutes ago, mjhardisty said:

KCSIE still says "where possible" for identifying the individual on the device, and its exceptionally difficult on tablets.

At least it does allow you to individually identify the device and time using that method.

That's made me spend some time going over the specifics in KCSIE - what you say is indeed referred to by SWGFL for example but not specifically referenced in KCSIE itself - it does however point to UKSIC which has this:

When shared devices are used, schools must ensure users log in individually. This allows monitoring systems to apply restrictions and configurations based on user profiles, improving the safeguarding process.

So very typical, never a straight answer  I'm inclined to agree with you on the "where possible" though.

Shared iPad testing, here I come! I'll report back anyway as I know this comes up often.

Thanks both for your input, much appreciated as ever!

[mjhardisty]

The "where possible" is referred in the DfE FIltering and Monitoring Standards.

https://www.gov.uk/guidance/meeting-digital-and-technology-standards-in-schools-and-colleges/filtering-and-monitoring-core-standard

 

Your responsibility would be to discuss both options with the DSL, discuss the pragmatics of each option for teaching and learning delivery (i.e. waiting/capability for pupils to sign in and out, etc) and then for the DSL to assess the risk and solution.

[tom_newton]

Ultimately, shard ipad is going to deliver future benefits (or lack of pain) too - less likely kids will "lose" work, by saving locally and letting the ipad circulate, decent auth brings opportunity, best to normalise it early before it becomes an absolute necessity

[synaesthesia]

Well this is another rabbit hole I didn't intend to fall into.

Apple's whole process for this is beyond diabolical. I hated them before, I *despise* them now! Not fit for purpose.

So apparently I have to wait 30 days because of 38 accounts I have nothing to do with using the domain name. I can't see what accounts those are. After that 30 days, Apple renames/changes those accounts so they're no longer locked to the domain then I can do what is needed.

Trying to test this with one user I could do something with, but password has long been forgotten. The password reset system for Apple is laughable - first I have to do it on an Apple device. Stupid, but OK - do that, it goes through the process and prompts for a trusted phone number, provide mine which I know is there - then it asks me for a pin code for a random iPad I also have nothing to do with. Thanks. The only other way around is to put in a reset request with Apple which may take several days.

If Tim Cook walked in here as part of some random retirement tour, I'd hand him to the year 8s for a flushing and beating.

 

A while ago, I made a positive comment on another thread about how Apple might be turning a corner - repairability and usage scenarios outside of the pure consumer level.

I take it all back.

 

[3s-gtech]

Yeah, went through that last year when I finally moved to proper Apple IDs synced to our accounts. I just waited for the timeout as there was other stuff I could do (no point getting stressed over that). It worked fine afterwards.

[tom_newton]

That's the thing with Apple's hoops - you just gotta jump through them. The system is built for people who actively enjoy colouring inside the lines

[36Degrees]

We're just going through this now - is there any way to force the student's account to log off when they close the browser? (We haven't gone down the AppleID route and also using Mosyle MDM which I am new to!!)