jadzea Posted June 6, 2023 Posted June 6, 2023 Hi, Having a few issues getting a policy setup for some Chromebooks going through Smoothwall transparently. It seems there are a number of URLs that Chromebooks need access to and the biggest sticking point I've got is google.com To get them to sign in for some reason I see to have to set google.com to DO NOT INSPECT for unauthenticated users, which has the result of anyone being able to search for stuff without it being logged. Does anyone have any advice or sample policies and categories they've created to get Chromebooks signing in without messing about? I think I've been round and round with this so many times now I'm missing the obvious..! Thanks in advance,
drewp Posted June 6, 2023 Posted June 6, 2023 Not sure if this will help, is the "Connect for Chromebooks" whitelisted in your webfilter policies and "Do not inspect" in your HTTPS Inspection Policies. https://kb.smoothwall.com/hc/en-us/articles/360002135604-Allowing-Access-to-Google-Services
tom_newton Posted June 7, 2023 Posted June 7, 2023 With chromebooks our agent based filter works really well - have a quick chat with your CSM and let's get it enabled
jadzea Posted June 7, 2023 Author Posted June 7, 2023 (edited) Ok so to give a bit more context… We use Office365 to provide authentication for Google Apps using SAML - it works well on PCs, iPads and other web browsers. The issue is specifically related to when signing into Chromebooks and Smoothwall’s HTTPS Intercept is involved. If we join the Chromebook to a network where we’ve disabled SSL intercept the sign in works fine, but when we don’t the Office365 sign in performs as expected but it then pop up momentarily with the wifi network chooser on the Chromebook, and then rolls back to the login prompt. We’ve even joined the Chromebook to a RADIUS network that uses smoothwall RADIUS accounting so that we know the device is effectively being treated as a user who can access google services etc without issue, but the issue persists. I’ll try and raise with smoothwall again, but does anyone know if it’s possible to get a more detailed log from smoothwall to show all the urls going through it from a device - the IP audit trail doesn’t seem to show an issue… Thanks. And sorry, yes I’ve got Connect for Chromebook set for DO NOT FILTER for everyone as a web policy and also DO NOT INSPECT IN HTTPS policies. Thanks for the suggestion. Edited June 7, 2023 by jadzea
tom_newton Posted June 8, 2023 Posted June 8, 2023 So the issue here is that before you sign in, the Chromebook doesn't have your policy, so doesn't have a MITM cert. At this point, if it needs to go to any site to sign in, you can't MITM it. Sadly this generally means not MITM'ing google.com - of course not something we want to do. You MIGHT find that there's some other domains we can unMiTM here to fix. The only fixes are to either sign in on Fifi network A, which is basically google open and nothing else, and then bounce to network B by policy. That's awful. The better solution is to put these chromebooks on an unfiltered network, with the Smoothwall filter agent on there. This is my preferred option. It filters the chromebook regardless of the network its on.
jadzea Posted June 8, 2023 Author Posted June 8, 2023 (edited) So the issue here is that before you sign in, the Chromebook doesn't have your policy, so doesn't have a MITM cert. At this point, if it needs to go to any site to sign in, you can't MITM it. Sadly this generally means not MITM'ing google.com - of course not something we want to do. You MIGHT find that there's some other domains we can unMiTM here to fix. The only fixes are to either sign in on Fifi network A, which is basically google open and nothing else, and then bounce to network B by policy. That's awful. The better solution is to put these chromebooks on an unfiltered network, with the Smoothwall filter agent on there. This is my preferred option. It filters the chromebook regardless of the network its on. Thanks Tom, appreciate your help with this - so to clarify, At the login screen on the chromebook the chromebook doesn’t have our Google network policy so it won’t have our HTTPS Inspection CA Certificate, which is of course needed to HTTPS inspection. Once we're signed in this is installed and so inspection to google services works correctly? If we use a “raw” google account (i.e. one that has been setup in our google apps domain to not use the AzureAD SAML Sign in) to sign in things work correctly so I really do believe this is related to the ACS URL that is used - is it possible to get detailed requests from the chromebook via smoothwall to see exactly what URL is being called or causing the issue? Thanks Edited June 8, 2023 by jadzea
tom_newton Posted June 8, 2023 Posted June 8, 2023 That's correct, yes. I would suggest the realtime log viewer should show any requests - limit it down by the chromebook's IP. We might get lucky and find a domain (remember you can't no-MiTM a URL, only a domain) that we are willing to let through unMitM'd. If you need a hand with that - fling in a support ticket, anc send me the ID so I can track it.
jadzea Posted June 8, 2023 Author Posted June 8, 2023 That's correct, yes. I would suggest the realtime log viewer should show any requests - limit it down by the chromebook's IP. We might get lucky and find a domain (remember you can't no-MiTM a URL, only a domain) that we are willing to let through unMitM'd. If you need a hand with that - fling in a support ticket, anc send me the ID so I can track it. Ah ok so this might make a whole lot of sense about not being able to exclude a URL from HTTPS Inspection, just the domain, so even something like http://www.google.com/acs/ wouldn't be excluded unless the actual domain Google was...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now