Hi, I'm surprised teachers would be able to correlate IP and location? Or do you mean you'll have done that before providing the reports? Because that'd be a significant overhead, rather than just having the reports set to send to teachers.
(On that note we're expanding the notifications/reports to include more info, to largely save anyone having to then log on to find out enough detail.)
Hi, none of our realtime pages show no data... Normally. Which one exactly is it that's not working for you?
As we go along, we’re gradually updating reports and creating news ones to ensure each has this information. This allows someone looking at a report much later or looking through many reports to see what the data is that they’re looking at.
It's not something we're actively going back and doing (it would take a little while), we we are updating them as we change them for other reasons, or any new ones we create!
16 votes4 comments · Smoothwall Filter (On Premise) » User Experience · Flag idea as inappropriate… · Admin →
This is planned, along with bringing this certificate for this under the banner of the new certificate management page in Edinburgh. For now though, it’s not currently covered by that page.
The help is wrong - we're getting it changed. We didn't get time to bring the cert for the admin UI under the banner of the new certificate management. The second link (screenshot) is correct - the user-facing HTTPS services cert does NOT cover the admin UI.
2 votes0 comments · Smoothwall Filter (On Premise) » Firewall & Routing · Flag idea as inappropriate… · Admin →
5 votes3 comments · Smoothwall Filter (On Premise) » Firewall & Routing · Flag idea as inappropriate… · Admin →
So are you asking us to support it, or not support it?
68 votes6 comments · Smoothwall Filter (On Premise) » Guardian Filtering · Flag idea as inappropriate… · Admin →
That's a really cool idea!
3 votes1 comment · Smoothwall Filter (On Premise) » User Experience · Flag idea as inappropriate… · Admin →
Could well be an issue with the connectivity to Uservoice – that’s all the pop up window on the Smoothwall is actually doing – it’s not just a straightforward form.
We’ll work it out…
Could well be an issue with the connectivity to Uservoice - that's all the pop up window on the Smoothwall is actually doing - it's not just a straightforward form.
Have you looked into whether your wifi controller can do something like that?
It's not something that we're likely to bake into Smoothwall as it's only real involvement in the wifi is for the purposes of identifying who the user is.
Hi Shane, which DHCP server are you using that makes assigning a reservation harder for some devices than others?!
I can see the use of MAC exceptions to bypass the need for creating a reservation, but MAC address would only be useful on the same subnet as the Smoothwall - where IP is useful regardless.
I'm not hugely familiar with Scrutinizer's capabilities.
But, it is very possible to see where a client is connecting to, even when they do it over HTTPS. In fact - even with decrypt and inspect off on a Smoothwall, we can still block connections because the initial connection request (which contains the destination hostname) is not encrypted. Once that's been identified, keeping track of the connection (for the purposes of flow information) is trivial. But Smoothwall does require decrypt and inspect to see the contents.
Hi Jay, I'm not sure what kind of switches you're using but you could potentially mirror the traffic direct to Scrutinizer?
This seems to be the place to start: https://www.plixer.com/Scrutinizer-Netflow-Sflow/configuring-netflow-ipfix-sflow.html
Another explanation from the same developer:
"We support NTLM authentication, and the only way to verify an NTLM handshake
is via RPC using a computer account. This is implemented in Smoothwall using
Samba, which also manages things like failover between multiple domain
controllers and automatic Kerberos configuration. The authentication service
asks Samba to resolve the username, which makes the decision to use RPC
or LDAP. RPC is preferred in this case because it is compatible with
more versions of Windows; other tasks do use LDAP.
So Smoothwall has access to the same information that those other systems
have, but its searches are more specific because it doesn't assume that you
have ensured usernames are unique in the forest."
He and I were talking, and it's theoretically possible to make the Smoothwall assume usernames are unique, but that has obvious drawbacks if that's not true...
We've added it to our (long) list of ideas, along with a few other intriguing ideas that have come from this conversation - so thankyou very much!
Glad to hear we were able to provide a work around!
I've been looking into your suggestion and one of our developers explained:
"Smoothwall actually uses RPC protocol to resolve usernames, not LDAP.
It has access to all user accounts, including those in other domains, but
the reason they have to qualify their name fully is to avoid ambiguity.
An unqualified username is unique within a domain, but two users in the forest
may have identical short names. This wouldn't change even if you used the global catalogue - the short names could still exist in multiple domains.
Here Smoothwall behaves in the same way as a Windows workstation would. If a
user logged into a workstation joined to a different domain, they would have
to qualify their username.
Users in a domain commonly authenticate using a single sign-on method,
such as Kerberos, NTLM, or a Kerberos login script, which means the domain
is specified automatically. "
So that might have been another solution - but would depend on your setup. If you're interesting in trying Kerberos login scripts (which is a relivitely new feature) then please contact support.
Hi, can you clarify... you'd like to delete all of what?
Doing that in the Smoothwall would just stop them getting through the Smoothwall - you'd really want to do this in the wireless system to stop them even getting on the network.