Smoothwall cloud filter extension - not picking up on-premise group mappings

[_techie_]

Hi.

 

Today we have had reported that the smoothwall cloud filter extension that is applied via GPO is not mapping AD groups to on-premise groups correctly, instead placing them in Default Users! This means that a lot of content is being blocked incorrectly!

 

I have put a workaround in place a the moment, to use no extension with a proxy applied, which seems to be working okay at present.

Any ideas? I am obviously missing something as the directory settings on our on-premise smoothwall appliance are reporting as working correctly.

Even tried a reboot of the smoothwall box to see if it resolves the issue, but no joy.

[BadgerPatrol]

In the extension diagnostics, are the users showing as completely unauthenticated, or is it showing the correct username and AD group memberships but not applying the Smoothwall group assignments?

 

We had the latter and had to switch to IDex v2 (despite it initially working with v1) and recreate the group mappings in the cloud. We then had a further issue following that where the cloud group mappings would disappear periodically, which was resolved by creating an Active Directory type directory on-premise (in addition to IDex), because apparently syncing from IDex on-prem to IDex in the cloud is too logical.

[_techie_]

is it showing the correct username and AD group memberships but not applying the Smoothwall group assignments?

Yes

Moving to a proxy setup works too.

 

I know we have around 6 servers with the Idex client on, and one DC with the Agent on, which we will be removing in the summer.

I don't believe this is the issue however, as both our chromebooks and Intune PC's are working correctly with the groups!

[BadgerPatrol]

Google and Azure directories are uploaded to the cloud by default, so those mappings will exist in the cloud. You need to install IDex Agent v2 and configure the cloud upload during the install in order to get the directory to appear in the cloud.

[_techie_]

Hi.

Thanks for your help.

I have now changed the setting on the group policy, that states "Enable Azure Active Directory" to be enabled on the Smoothwall Unified client.

This seems to fix the issue in both Edge and Chrome.

 

I will tidy up the remaining IDEX stuff in the hols.

[simpsonj]

Having the same issue, I think after updating to latest version of Smoothwall (Leeds-66), apart from I'm not using Idex or Azure AD, just on-premise AD, which was working fine up until this point! Now all users of Windows devices are being mapped to the Default Users group.

 

Out of interest, how did you put in the workaround, to use no extension when proxy is applied?

[_techie_]

Well we are syncing groups to Azure AD as well, so you will need to set this up in smoothwall >>> directories, and make sure any smoothwall filtering related groups in AD are being synced to Azure using Azure AD Connect. Also make sure any domain computer accounts that are being used are also synced to Azure if you are doing Seamless SSO for Office/OneDrive/Edge.

 

In the group policy under Computer Config - Smoothwall, I set the Enable Azure Active Directory setting to be Enabled (default is disabled). This is for the unified client. This cured my issue without having to resort to the IDex Directory, which I would rather not use.

[simpsonj]

Thanks, but I'm not using Azure AD (yet), instead I'm just using an on-premise AD, which was all tickety boo until I updated to Leeds-66!

@ibpalle any ideas?

[_techie_]

Hi.

If your totally on-prem, I would stick with a proxy setup, and push out proxy settings to the browsers using GPO for students, teachers, and office/support staff.

I would agree with on you Leeds-66, something definitely changed without me making any internal changes.

 

Don't forget you will need your HTTPS inspection certificate deployed via GPO too, as I think HTTPS inspection is on by default - might be worth checking your IP's here too, and putting any servers in a specific location on smoothwall for no HTTPS inspection too as well as auth through the filter as something more than Y7 students.

Either that or setup some specific allowed categories for your whitelist for things like Windows Update etc for your servers.

 

Hope this helps.

[simpsonj]

Thanks, the general setup of Smoothwall is fine, but there's been a change of behaviour to how our onprem Smoothwall talks to our Cloud Filter.

 

If it's the case that the Cloud Filter can no longer be used with an onprem AD, that's not great and I'll need to push to Azure AD quicker than I'd like. Either that, or I remove the Cloud Filter extension from staff Windows laptops, and just use it on our Chromebooks. I just don't know if this was intentional from Smoothwall, or a bug introduced with Leeds-66.

[_techie_]

Smoothwall's response was to use the IDex directory, but I don't really see why your using the cloud filter if your totally On-Premise? Unless your teacher laptops go offsite, and you don't want to mess around with providing ways of switching Proxy and and off....

The alternative for that would be transparent filtering tied to a VLAN/Location.

If that's the case, I would seriously look at Intune Managed devices, sadly there is no real alternative to managing mobile devices if they leave the site (securely anyway).

 

Thanks,

[simpsonj]

1:1 Chromebook devices for students is the reason I have a Cloud Filter! That part works perfectly.

 

Also, teacher's remembering to turn the proxy on and off was a complete PITA, so I added the Cloud Extension to their Windows devices, which, up till a week ago, also worked very well.

 

The vLan/Location filtering could work for onsite, but I suspect the original issue would rear it's head offsite.

 

InTune is on my list to look at. If everything could work the way it's supposed to, I would have the time to implement it

[DrCheese]

I got hit by this as well, after updating to Leeds 66 (That'll teach me for doing an update the week before going on holiday!)

I had my Azure AD sync'd to the cloud filter & had assumed that the Windows client had always been using that when offsite - Apparently not. Had to turn on the AzureAD option in group policy to fix this as well.

 

Mildly annoying that this wasn't mentioned in the release notes for Leeds 66 at all, else I would have been prepared.

[tom_newton]

Can folks chuck me some ticket IDs? Shouldn't see any changes in 66!

[_techie_]

Hi Tom.

This was my ticket ID: 438604

The issue seemed to affect Hybrid Azure Joined Devices (not intune managed in our case).

The cloud filter wasn't mapping the AD On Premise groups correctly (all users ended up in the Default users group on the cloud filter status page), despite working before Leeds 66, so we ended up overblocking a bit too much really for Staff.

Once the group policy setting for the smoothwall Unified Client: Enable Azure AD was set to be enabled, this resolved our issue.

We were both before and after the incident mapping our Azure Directory on our Smoothwall S9 appliance.

 

Supports recommendation was to setup the IDEx directory....

 

Hope this helps.

[simpsonj]

@tom_newton

 

My ticket ID is: 439726

 

Support went the iDex route, which I've installed and support has configured for me, so I'm back up and running now.

[DrCheese]

Leeds-67 is out, which has this in the release notes

 

Ref. 68354 Resolves an issue where it is possible to pass empty groups the the cloud during sync.

[tom_newton]

We have dug deep into this and found a few issues - nothing to do per se with 66, or any cloud side release, but more of a confluence of a number of things. 67 is being added to, and will be re-released. All customers with open issues are being tracked, with the aim of making sure there's no wrinkles before month 9.

[DrCheese]

We have dug deep into this and found a few issues - nothing to do per se with 66, or any cloud side release, but more of a confluence of a number of things. 67 is being added to, and will be re-released. All customers with open issues are being tracked, with the aim of making sure there's no wrinkles before month 9.

 

Brill thanks - Thought I was going mad when the tickets originally started coming in!