Schools using GCPW and Smoothwall

[TwistedHelixis]

It must be possible, as a competitor got their filter working, apparently by adding something into Registry and then using that to call the name from.

[paulkerton]

It is absolutely possible to do it.

We worked with the competitior to find where in the registry Google was storing the email address on login. We also had the added bonus of multiple domains, so we had to pick up the user on login with their full email address as well as setting the use_shorter_account_name reg key in GCPW and forcing Chrome to sign in with the account on login.

Because of the multiple domains it would just pick up the first user it found. So we had to find another reference on login, not just the short name. This does rely on having a local agent on the machine though, obviously.

It was in HKEY_CURRENT_USER\Software\Google\Accounts I believe. Don't quote me though!

Edited December 15, 2025 by paulkerton

[dhicks]

1 hour ago, whartomt01 said:

can the URLs that GCPW use not be allowed on a default profile before sign in. Once logged in, extension kicks in?

 

Smoothwall isn't filtering the Google-hosted endpoints GCPW (or just general web-based login-with-Google pages) uses, users can log in to machines using GCPW okay. The problem is that, once logged into a machine, the Smoothwall appliance doesn't know the username of that logged-in user - GCPW creates a local Windows user. If we install Smoothwall's Windows client, it picks up the username as if it's a local user, with the local machine name (domain) as part of that username, i.e. something like "TESTMACHINE01\u.name" instead of "[email protected]".

 

As @paulkerton points out above, this should be quite solvable with a (hopefully) simple modification of the Smoothwall client to return local usernames in a different format. Possibly the client could look for a regular expression to modify usernames with, something defined as an option in the registry maybe.

Edited December 15, 2025 by dhicks

[whartomt01]

2 minutes ago, dhicks said:

 

Smoothwall isn't filtering the Google-hosted endpoints GCPW (or just general web-based login-with-Google pages) uses, users can log in to machines using GCPW okay. The problem is that, once logged into a machine, the Smoothwall appliance doesn't know the username of that logged-in user - GCPW creates a local Windows user. If we install Smoothwall's Windows client, it picks up the username as if it's a local user, with the local machine name (domain) as part of that username, i.e. something like "TESTMACHINE01\u.name" instead of "[email protected]".

Sorry I was talking about the cloud filter

[dhicks]

1 minute ago, whartomt01 said:

Sorry I was talking about the cloud filter

 

Ah, does that handle user identification differently? I'll have another look at the cloud filter settings.

[whartomt01]

Spoiler

 

Id presume it's like the Smoothwall Monitor extension. through the google account rather than the AD/Local machine account.

 

But I haven't used it so not sure. Let me know how you get on

Edited December 15, 2025 by whartomt01

[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...

 

Ah, okay, that's starting to make sense. Seemingly, RADIUS can handle both authentication and accounting (but, possibly, not authorisation, which is something different). I have a basic (Python) test RADIUS client which I'm trying to get to account against the Smoothwall server. Do we actually need a whole separate RADIUS server, or will Smoothwall act as a suitible RADIUS server for both authentication and accounting? If a client device (a Windows client machine, in this case) can send a RADIUS accounting packet to the Smoothwall server, does that tell the Smoothwall server which user is now logged in? If that is so, it should be quite do-able to write a RADIUS client that runs at user login time (and at 2 minute intervals, if needed) and accounts wirh the Smoothwall server. I can probably write that in Go and compile it for different platforms, too, which would be handy.

[tom_newton]

Unless I am very much mistaken, if you do radius accounting the smoothwall simply doesnt care if a radius server exists. All it cares about is does a radacct packet arrive from a trusted source (you may have to maker all your IPs trusted)

[psydii]

46 minutes ago, tom_newton said:

Unless I am very much mistaken, if you do radius accounting the smoothwall simply doesnt care if a radius server exists. All it cares about is does a radacct packet arrive from a trusted source (you may have to maker all your IPs trusted)

That seems unwise. Is that not open to privilege escalation (in the most high-level sense of privilege and escalation) “oh hi smoothie, you trust me right? Well  I’m actually the Head Teacher, now let me get to all the AI Sites, KThanxBye.”?

[tom_newton]

Sure. It's deeply sub optimal, but might represent a reasonable interim. It's true of any system that relies on identity that isn't auth 

[psydii]

Yeah it just makes me sad that its 2025 the suboptimal interim solutions first seen in the early 2000's  (late 90's?) are still in play.

 

I'm also aware that the maker of the most popular browser in the world has almost as a core value, a philosophy that  requires them  to make this sort of thing as close to impossible as is practical.

 

 

[dhicks]

3 hours ago, tom_newton said:

Unless I am very much mistaken, if you do radius accounting the smoothwall simply doesnt care if a radius server exists. All it cares about is does a radacct packet arrive from a trusted source (you may have to maker all your IPs trusted)

 

Okay: is the Smoothwall appliance itself not a RADIUS server? As far as I can figure out so far, RADIUS seems to be two protocols, working on two different ports. I'm part-way through getting a basic Python client working on a test machine. At the Smoothwall end, I've enabled the two required ports on the firewall settings, letting (accounting) RADIUS traffic through to the Smoothwall device. The Smoothwall device can connect to various directories, therefore can it also do authentication via RADIUS?

 

As @psydii points out, writing a proper production-ready client is going to need a bit more than a Python script running as a given user. The shared secret between the client and RADIUS server is going to need to stay secret, otherwise any user could use it to tell the server they are whatever user they fancy. Therefore, on Windows, the secret and the code to read it are going to need to be segregated away from standard users, therefore probably needing something split into two components.

 

If a machine uses Smoothwall as a RADIUS server to authenticate at user login time, does the Smoothwall server then reliably know who that user is? We're using pGina as our Windows login handler, which does have a RADIUS authentication option, so that might fit out use-case better.

[paulkerton]

1 hour ago, psydii said:

 

I'm also aware that the maker of the most popular browser in the world has almost as a core value, a philosophy that  requires them  to make this sort of thing as close to impossible as is practical.

 

 

I'm also aware that the maker of the most popular Operating System in the world has almost as a core value, a philosophy that requires them to make this sort of thing as close to impossible as is practical.

I'll just fix that bit for you as it's Microsoft that makes this difficult. Repeatedly. It's Microsoft that makes it nigh on impossible to use local accounts, it's Microsoft that make it so we can't use hardware keys with GCPW login screens. It's Microsoft that have spent the best part of a decade fighting legal challenges by the EU over their interoperability. 

I've got interop between Google Meet Hardware, WebEx and Zoom working just fine, whilst i'm currently having to pay for a solution to make interop with Teams possible.

[psydii]

 

Why isn't there a way for Chrome to securely pass the auth token to the proxy?  That would be entirely OS agnostic and thus a win on every platform!  Because Google don't want to.

 

It's not Microsoft that is at fault in this *specific* case.

 

@dhicks If I were to naively designing a solution, it might look something like:

Proxy Server/filtering platform runs on a host that is its own KDC.

Client machines run service that authenticates the local service to the proxy's KDC (to ensure proxy-client trust)

Client machine run a per-user service that presents the user's local auth token to the machine-wide service,

i.e. The per-user service says to the machine wide service "hey, I'm running as local\user1 here's my auth token". the machine wide service validates the user token and translates the username  to cloud-equivalent username.

The machine wide service then sends that (securely) to the proxy service, which in turn looks up group membership etc against the cloud auth provider, and returns a token (probably just text string rather that anything Kerberos or OAuth like) to the user client (or maybe the machine-wide client, depending on how OS/Browser security really works)

The local service then injects this token into the header of all HTTP traffic which the proxy service then uses to make filtering policy decisions.

 

Easy. To be honest I'd be surprised if Tom doesn't just use that as an LLM Prompt and have the code pushed to customers by lunchtime. 

 

 

 

[dhicks]

22 hours ago, psydii said:

Easy. To be honest I'd be surprised if Tom doesn't just use that as an LLM Prompt and have the code pushed to customers by lunchtime.

 

I suspect / hope Smoothwall have a bit more of a testing pipeline involved in their development process. It would be nice if that process was a bit more transparent / agile - this problem (Windows client needs some modification to add an option for people using GCPW and similar login handlers for Windows) seems like it should be sortable, you would think we might be able to get a good time estimate as to when the feature might be added to the client.

 

Interestingly, asking Google's Gemini to produce some code to help has it tell us to set the registry key "HKLM:\SOFTWARE\Policies\Smoothwall\UnifiedClient\Domain" to "@ourdomain.com". Is this accurate, or is that something Gemini has just made up?

[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...

 

Okay: is there any documentation on what the Smoothwall server expects to see in the RADIUS accounting package? I have a test utility on a Windows machine sending an accounting packet to Smoothwall's port 1813. That packet includes a "User-Name" attribute and, of course, the RADIUS shared secret set on the Smoothwall end. The packet seems to be received by the Smoothwall device okay, I'm getting a "Accounting-Response" message back. That doesn't seem to be affecting how the Smoothwall device sees any requests, though - if I go to https://smoothwall.outdomain.com:442/clogin I don't see an already logged-in user listed, and filtering does not seem to be applying how I would expect.

[psydii]

1 hour ago, dhicks said:

I suspect / hope Smoothwall have a bit more of a testing pipeline involved in their development process.

I'd hope so too.  To be clear, everything from the word "Easy" was 100% tongue-in-cheek/a joke.  The bit before, was  me genuinely spit-balling how I might approach this with only a vague recollection of how Kerberos/KDCs work from a 2000-era MCP course and basically no programming experience. 

[dhicks]

11 minutes ago, psydii said:

The bit before, was  me genuinely spit-balling how I might approach this with only a vague recollection of how Kerberos/KDCs work from a 2000-era MCP course and basically no programming experience. 

 

I think (possibly) that the most usable / applicable solution is going to be something-to-do-with-RADIUS. This thread is about Smoothwall and GCPW, which is relevant to my particular case, but we do also have a bunch of Macs and Chromebooks on the network and a guest wireless network to integrate, so for us a RADIUS-based solution might be good. Being able to tell the Smoothwall server that a particular user has just logged on to a managed device via RADIUS would also be handy for people just trying to get logins with GCPW working with Smoothwall. @tom_newton seems to suggest it might work, but I suspect I might need to add a few more fields to a suitible RADIUS accounting packet for Smoothwall to pick it up.

[psydii]

Sounds like you have a far better handle on this that I. Nobody should take what I have to say on the actually technical bits of a filtering platform too seriously.  I've not poked around with proxy auth since Pavilion Internet's NINAA and very early RM IFL offerings.... which is why I'm surprised/disappointed that the current best-available solution (for auth) still seems to be from a the same era.

Edited December 17, 2025 by psydii

[dhicks]

3 hours ago, dhicks said:

is there any documentation on what the Smoothwall server expects to see in the RADIUS accounting package?

 

Ah! Asked Google Gemini and got an answer that said to set:

• User-Name: i.e. [email protected]
• Framed-IP-Address: The IP address of the client machine.
• Calling-Station-Id: The MAC address of the client machine.
• Acct-Status-Type: Start (user connects), Stop (user disconnects), Interim-Update.
• Acct-Session-Id: A unique ID for the session. "12345" seems to work.

And that seems to work! I sent the above with a Windows RADIUS test utility and subsequent browsing does seem to be filtered as the appropriate user. The Gemini-generated result contained a link to this thread:

 

That's handy to know - Smoothwall might not be able to authenticate users with a Google / Azure (i.e. OAuth) backend, but it can lookup usernames. I wonder if we can add Google LDAP as an "Active Directory" server to Smoothwall?

 

Right, okay!: who wants to write a replacement (or addition) for the Smoothwall client that sends RADIUS accounting packets to the server, then? The client needs access to the shared secret used to authenticate RADIUS clients on your Smoothwall server, so it'll need to keep that safe, but otherwise it should be reasonably simple functionality imported from a library or two. Maybe write it in Go, then we can compile a cross-platform binary for MacOS / Linux / etc as well?

[tom_newton]

Sounds like you have a handle on it - and if the username matches something in your google directory, yes, the Smoothwall will do group lookup there

[dhicks]

On 17/12/2025 at 16:00, tom_newton said:

Sounds like you have a handle on it

 

Indeed. Seemingly, your internal development team can't give us a timeframe for being able to update your Windows client, and that client has issues handling Fast User Switching. Do you have any idea what the problem is, or is it just a general other-stuff-to-be-done-first sort of problem?

 

If I send a RADIUS accounting "Start" packet to the Smoothwall server at login, do I have to send proper "Interim Update" packets at intervals, or is just the Start packet okay? Is there a timeout period set for logins? Some of our Windows workstations probably get logged in to on a Monday and not logged out rebooted / logged out until Friday (when we do a forced reboot for updates).

 

It should, hopefully, be easy enough to write something that can run as a basic Windows service in the background, checking the current user and sending updates to the Smoothwall server periodically. This should handle both timeout periods and fast user switching. Can it just send "Start" packets each time, or does it need to send proper "Start", "Intermediate Update" and "Stop" packets?

 

Bearing in mind this service is for managed Windows installations, not home devices, we should be able to use the "query user" command to get the most recently logged-on user.

[tom_newton]

I don't think there is a timeout on radius. 

I'll chase the underlying issue up with the agents team in the new year. 

 

 

[dhicks]

On 21/12/2025 at 13:36, dhicks said:

It should, hopefully, be easy enough to write something that can run as a basic Windows service in the background, checking the current user and sending updates to the Smoothwall server periodically.

 

Okay: initial, very basic, v0.1, not-ready-for-production RADIUS client:

 

https://github.com/dhicks6345789/radius-user-client

 

This is written in Go, and should be compilable for Windows, MacOS, various Linux platforms, etc. So far I've been building and testing on a Windows server machine, so I've just got a basic Windows build able to send a suitable accounting packet to the Smoothwall server when run from the command line. The build script compiles the executable and packages it up in a Zip file along with the config and install scripts. My thinking is that you can distribute the Zip file around your devices, then have a script unzip that file and run the install script locally.

 

The executable doesn't currently run as a service, I hope to be able to sort out that bit this week on a client test device.

 

This is a very early, basic version, so comments and suggestions very much appreciated.

[dhicks]

On 21/12/2025 at 13:48, tom_newton said:

I'll chase the underlying issue up with the agents team in the new year.

 

Any progress / updates on this? We've had to spend time writing our own user-reporting client to report users via RADIUS, now I'm having to figure out how to stop your Chrome extension loading on some machines so it doesn't then override the RADIUS-reported username.