dhicks

Gah! No, you're right - the Smoothwall RADIUS accounting implementation seems to expect the IP address of the client device in a "Framed-IP-Address" attribute - a quick Google suggests it is defined in RFC 2865 as Attribute 8, which sounds like it's a fairly well-known, standard attribute. Does UniFi send the IP address in a different field, then? As you point out, you can (and do) solve this by using an intermediate local server that accepts the RADIUS packet from the UniFi system and passes something better-formed to the Smoothwall server. However you, like us, want to reduce the number of local servers / services to maintain, not add to them. The solution in your case might be to install Smoothwall's Unified Client (assuming we're talking about school-managed devices here), which should be able to report the current logged-in user's username to the Smoothwall server. There's a registry setting you have to set to get it to report Azure AD usernames correctly. If that isn't suitable (as it isn't for us, as we're using pGina / Google's GCPW for Windows logins), I've just written a similar client that sends the username / IP address to Smoothwall via RADIUS - other thread: As that thread points out, the client isn't ready for production yet, but if you think it might solve your problem and you have a little time to try it on a test device that would be handy. Separately from that, for guest users we were hoping that we would be able to have identifiable usernames of some sort logged against any blocks / alerts on our guest network so we could better pinpoint the cause. It sounds like we might have an issue getting the UniFi server talking directly to our Smoothwall server. Like yourself, I can probably stick an intermediate server between the two (probably FreeRADIUS for us), but I would very much prefer not to if possible.

Ah - we're just looking at putting in a guest WiFi SSID, with our UniFi system talking to our (new) on-site Smoothwall appliance to inform it about guest users. I was hoping / guessing this would be a nice and easy thing to set up, have you found that the UniFi server has difficulty talking to the Smoothwall server, then? Sorry, this isn't helping your original question, quite the opposite (I'm asking you for help!), but at least two of us trying to figure out the solution might be useful.

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.

Yes: we have login-with-Google (OAuth) set up on our internal Smoothwall appliance, which needs a defined domain name (e.g. smoothwall.example.com) so that Google's OAuth implementation has somewhere it can see for OAuth authorisation callbacks. This means people with non-managed devices can sign in to the appliance with their school Google accounts to get appropriate filtering if they want (otherwise they just get filtered at the default, strictest level). I suspect this won't be used much, if at all, once we get the Windows client for managed devices working (which might take a few weeks for me to write) and get our WiFi system (Ubiquiti UniFi) configured to be able to hand out guest logins for visitors.

Much the same as you, we have an internal print server (Papercut) and door entry system (Paxton / Inventry), both of which are fine using internal IP addresses. We do have a couple more servers (remote desktop, applications), but those are accessed via a Cloudflare zero-trust tunnel using Cloudflare's (external) DNS server. The only reason we've just had to re-introduce an internal DNS server is with the switch to Smoothwall for our filtering, which needs a defined domain name (e.g. smoothwall.example.com) to be able to handle login-with-Google SSO. Smoothwall acts as its own DNS server, though, so it's not something we need to think / worry about.

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.

Policy-related friction: I'm not quite sure exactly what that is - probably people aren't asking me about general school policies, so it's not something I think much about. People do ask me IT-related queries, though, and an AI to answer those might be handy. I've just tried putting some of our How-To documents into Google's NotebookLM. A reasonable result - I was able to ask it things like "How do I change my password?", "How much are replacement key fobs?", etc. The user interface would be a bit slow to add (or refresh) our whole document library in one go, so API usage there would be handy, and there is a limit of 300 resources in one Notebook, by the looks of things, but for an internal tool it looks very useful. @TechMonkey mentions (Microsoft's) Copilot above, which sounds like it has similar capabilities. I don't think our staff would necessarily think about an AI system being limited to only approved documents, hence we currently limit them to using approved tools (Google Gemini for us). Red flags / requirements would simply be an AI system that wasn't based on an already-approved tool, hence needing some sort of separate approval process to be gone through before it could be used. Basically, a nice front end with a choice of a Gemini / Copilot backend as appropriate per school would be handy, any other backend would need separate approval. I wonder how similar the features of, say, NotebookLM and whatever the Copilot equivalent is? For curriculum materials, I wonder if I could produce a bunch of documents (text, images, video and audio, by the looks of things), a folder's worth per subject, then a teacher could simply point a NotebookLM or similar at it for an instant AI chatbot on that subject. For history it might be useful / more engaging for replies to be first-person, as if the historical character is giving answers, although I'm not sure.

Ah: no, it seems you can't currently make a Enterprise / Education Workspace account NotebookLM public. You can for a consumer account, though. API access to have the content of the NotebookLM auto-update is only available for Enterprise (not sure about Education), not consumer. It looks like the (Google) solution is to use the Gemini File Search API.

Ah, so could we upload all our policy documents and then have a handy interface to query those? Can that interface be public and/or embeddable in a web page? It would be nice to be able to have, say, at the top of the "policies" section of the school website an embedded section saying "Ask a policy question".

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?

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.

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.

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?

Other options I can think of: A Raspberry Pi mounted on the back of a small touch screen. Hardware cost probably not actually that different. You can set up / configure / write the software however you want, but it does mean you've got to spend time / effort on it. A full-flip laptop / Chromebook in "tent" mode. Might be free / cheaper if you get a pre-used one. If a Chromebook, then you'd need to be able to set it to act as a kiosk, which requires (I think) a Google Workspace setup and an appropriate license for the device. Might be useful if you want to look at how to do ChromeOS kiosk devices, might be a bit much otherwise. If you can get a device you can install Linux on (some Chromebooks, possibly) you can configure a kiosk setup yourself, although again if you've not done that sort of thing before you'll need to spend some time figuring it out.

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.

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.

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

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.

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.

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?

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

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.

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?

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

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.