Schools using GCPW and Smoothwall

[ThatBoringBloke]

Are there any schools out there that use GCPW to authenticate ON SITE Windows devices who also use an ON SITE Smoothwall?

 

I'm just trying to find out how you authenticate your Web traffic?

 

GCPW is not supported by Smoothwall, so there is (apparently) no way to directly pass the Google Authenticated User onto Smoothwall without directing to a SSL login page where they can sign in with their Google credentials.

This means that until the user manually signs in all web traffic is identified as Unauthenticated, which is a no no from a safeguarding point of view. Whilst Staff will happily sign in when they hit a block page, students are less likely to do so.

 

Smoothwall currently filters all Unauthorised IP's as part of our KS3/4 Blocks, so short of having to change this around I'm looking for suggestions. 

[tom_newton]

I'd suggest use the cloud filter extension. 

There's no way for an on prem device to pick up cloud auth (Google doesn't support kerberos) so that's probably the best bet 

[ThatBoringBloke]

12 minutes ago, tom_newton said:

I'd suggest use the cloud filter extension. 

There's no way for an on prem device to pick up cloud auth (Google doesn't support kerberos) so that's probably the best bet 

 

Cloud filter doesn't work with CGPW, I tried. Once you install the cloud filter GCPW just flashes up white and disappears. Remove Cloud filter and it works again. 

I spoke with David Navin / Josh McTighe about this issue.

[tom_newton]

OK, sure I've seen schools where it has, let me do some digging 

[dhicks]

On 20/11/2025 at 13:46, tom_newton said:

There's no way for an on prem device to pick up cloud auth (Google doesn't support kerberos)

 

We're just looking at this now. Our Windows devices log in with pGina which, similalry to GCPW (or other Windows login providers), Windows sees as a local user with the local machine name as the domain ("TEST001\pupil1"). The installed Windows Smoothwall client seems to be picking up that whole username to pass to the Chrome plugin, so the Chrome plugin thinks it is trying to filter a user called "TEST001\pupil1", rather than "[email protected]".

 

Is there maybe a setting we can configure, either on the Smoothwall appliance or in the configuration for the Windows client, to tell Smoothwall how to parse the username? A Regular Expression of some sort, maybe?

[tom_newton]

We're looking at the best way to achieve this right now...

[dhicks]

19 hours ago, tom_newton said:

We're looking at the best way to achieve this right now...

 

Are you likely to have a solution working and ready to roll out by the end of this week / next week? Your Windows client currently has a couple of config options it reads from the registry, could you add another registry entry that defines a regular expression for the client to apply to the usernames it picks up from the local machine?

[tom_newton]

I doubt it - it's looking like it might need a code change. Are you currently working with any of our engineers? If so can you ping me a DM with who/ticket # - just so I can escalate importance

[dhicks]

3 hours ago, tom_newton said:

Are you currently working with any of our engineers?

 

The interactions with your support staff are being handled by a different member of staff at this end, not me, sorry. I think we have our issue figured out - we ignore the Windows client completly and just point users at the Smoothwall gateway's login page instead, where they can log in with their Google login. Has the advantage it should work on other platforms, too (i.e. our pupil iMacs). We just need to figure out how to add a link to the login page from the "You have been blocked!" message page.

[tom_newton]

Good workaround - LMK if you need any help with making that link. 

[TwistedHelixis]

We also are having issues with GCPW and Smoothwall cloud, but its our LA that host the Smoothwall system, so I don't know if we will be able to point clients at the gateway. I know the local authority contacted Smoothwall on behalf of all the school in our county last year, but didn't get anywhere.

 

Ill keep checking back for updates.

[dhicks]

21 hours ago, tom_newton said:

LMK if you need any help with making that link. 

 

Yes, please. I'm logged in to our Smoothwall Cloud Management Portal (at portal.smoothwall.cloud), I've selected the (only available) "Filter" option and under "Settings" I can only see a simple on/off button for "Show detailed Blockpage information". There's no options there to modify the block page to link to (or embed in the page) anywhere for the user to log in.

[tom_newton]

On a train so limited in screenshot etc, but this is a change you want to do on the on prem ui. On prem has currently loads more block page options than cloud 

[dhicks]

22 minutes ago, tom_newton said:

On a train so limited in screenshot etc, but this is a change you want to do on the on prem ui.

 

Ah!, there's a whole "Blockpage Server" item right on the dashboard! Any idea if the uploaded image option supports animated GIFs? I'm thinking a picture of the headmaster wagging his finger at the user...

[tom_newton]

It should do! Go for it! 

[dhicks]

On 09/12/2025 at 14:43, dhicks said:

I think we have our issue figured out - we ignore the Windows client completely and just point users at the Smoothwall gateway's login page instead, where they can log in with their Google login.

 

Ah, drat. We've just realised this doesn't work very well for shared devices, our classroom Windows workstations in particular, where subject teachers move around between classrooms during the day, logging into different (Windows) workstations around the school. If they log in to the Smoothwall appliance via the web-based login page that whole device is then thought to be being used by that user. If the user logs out of the Windows machine without logging out using Smoothwall's web-based logout then the next user to use that Windows machine is still assumed to be the first user. I think this is the whole idea of your locally-installed Windows client - if it's present, it overrides anything else and tells the Smoothwall appliance the current user. The only problem there is that it's reporting the user as "MACHINE0XX\u.name" rather than "[email protected]".

 

It sounds like fixing the above requires a code change for the Windows client. It sounds like this might be a bit of a slow process at your end, I'd guess features have a bit of a pipeline to work through before they get released into an avilable update. Can we write our own client to report the user to the Smoothwall appliance / local browser plugin, is there any API documentation available that would help?

[dhicks]

14 minutes ago, dhicks said:

Can we write our own client to report the user to the Smoothwall appliance / local browser plugin, is there any API documentation available that would help?

 

Ah! Pretty much - a quick spot of Googling brings up your documentation page about Kerberos Authentication Scripts:

 

https://kb.smoothwall.com/hc/en-us/articles/360002135884-Set-up-authentication-with-Kerberos-Authentication-Scripts

 

It looks like we'd just need to modify a script to return usernames in the appropriate format and distribute it around our devices (via our MDM rather than Active Directory in our case, but should all be quite sortable). Looks like it even supports our MacOS clients, too.

[TwistedHelixis]

Quote

t looks like we'd just need to modify a script to return usernames in the appropriate format and distribute it around our devices (via our MDM rather than Active Directory in our case, but should all be quite sortable).

 

Good luck. Keep us posted 🙂

[tom_newton]

Probably the easiest way to send that sort of info to the smoothwall is a radius accounting packet... KRB requires cryptography

 

 

[dhicks]

Okay: no, simply running that Kerberos Authentication Script doesn't seem to do anything. What we were aiming for was a script to run at user login time that would contact the Smoothwall server and tell it the proper username of the user that had just logged in or, at least, tell the server that a (unknown) new user had logged in and that they need to be filtered at the "default" level until they log in with a valid school username. Getting this to work is, possibly, something-to-do-with-Kerebos or something-to-do-with-Radius. Whatever the problem is, it really should have been handled at implementation time by Smoothwall's deployment team.

 

On 12/12/2025 at 12:26, tom_newton said:

Probably the easiest way to send that sort of info to the smoothwall is a radius accounting packet... KRB requires cryptography

 

I will try and figure out what the above line means.

 

In the meantime, we've figured out that we can log the current user out by doing a simple POST ("ACTION=Logout") request to the https://smoothwall.ourdomain.com:442/clogin endpoint. It seems we have to log out using the browser the user logged in with so a session cookie is present - we can't simply log out from any browser / do a POST request from the command line. This means we wind up having to do the logout at user logout time from a workstation, not simply at login time when the next user logs in.

 

It is easy enough to create a simple web page that calls the endpoint (via a Javascript call in the body onload handler seems to work), and we can load that page from the command line in a headless instance of Chrome and/or Edge. We'll test how well this works as part of a logoff / restart script.

[dhicks]

On 12/12/2025 at 12:26, tom_newton said:

Probably the easiest way to send that sort of info to the smoothwall is a radius accounting packet... KRB requires cryptography

 

Looking at Smoothwall's documentation here:

 

https://kb.smoothwall.com/hc/en-us/articles/360003986299-Authentication-Methods

 

The "Kerberos Authentication Scripts" method would seem to be ideal- we can configure a script to run at user login time, and a script should be something we should be able to modify ourselves to fit our particular requirements. RADIUS would seem to be for authenticating between a wireless system (Ubiuiti, in our case) and Smoothwall, in particular for BYOD / guest devices - a separate problem, and one that we'll concentrate on to later. I could be wrong there, do please say if so.

 

The Kerberos Authentication Script provided by Smoothwall basically looks like this:

 

Dim winhttp
Set winhttp = CreateObject("WinHttp.WinHttpRequest.5.1")
winhttp.setproxy 1
winhttp.Open "GET", "http://smoothwall.ourdomain.com:814/"
winhttp.SetAutoLogonPolicy(0)
winhttp.Send

 

When I run the above script, no result / error message is returned. Checking the https://smoothwall.ourdomain.com:442/clogin page shows it still thinks I'm logged in through my Google account login, the login username hasn't changed to the local machine-style username.

 

Should the above script be working, is there some setting we need to tweak either client (Windows) or server (local Smoothwall server appliance) side? Is there anything further we can add to above script to maybe help with trouble-shooting?

[tom_newton]

My thought is that kerberos would need a local AD - have you still got one? And would require the user to be a domain joined user.

 

[dhicks]

34 minutes ago, tom_newton said:

My thought is that kerberos would need a local AD - have you still got one? And would require the user to be a domain joined user.

 

No, we no longer have an Active Directory server. I'm not familier with Kerebos or RADIUS, it would take me a while to read through any documentation and get my head around the terminology used. I can understand the idea of having a simple (Windows, although ideally MacOS and Linux as well) client that runs at login time and, in some trusted manner, tells the Smoothwall server the username of the just-logged-in user. This seems to be what your Unified Client application does, with the one limitation being that it doesn't (currently) have any way for us to modify the username sent from the client so that it matches the format unserstood by the Smoothwall server.

[tom_newton]

Yeah, that's our challenge here - not having an actual proper logged in windows user. I have raised this with the filtering PM team.

[whartomt01]

can the URLs that GCPW use not be allowed on a default profile before sign in.

Once logged in, extension kicks in?