Smoothwall Cloud Client, Intune PCs and Authentications for users

[Ironside]

Hi all,

We are steadily moving towards Intuning our PCs - however, some of our staff when trying to browse are getting treat as Students. Looking in the web filter logs, it says the username is the PC's ip address, which indicates that this PC isn't getting authenticated.

Now, if they go to something that students can't access, they get prompted to sign in, and can sign in with their credentials (their username and password as stored on local AD, not email and password as per Intune/M365), which is a solution, but i'd rather try to understand how to get Intune logins to naturally authenticate as themselves.

We have a directory setup for use with Azure AD, but also have our previous directory set up with Local AD - do we have to change the order of our directories so the Azure AD one is above the IDex directory or our Local AD directory?

[tom_newton]

Possibly easier to move away from on-prem filtering these users, and use the cloud filter client?

[Ironside]

That's the browser extension, yes? The extension is being installed by intune, and we have a Smoothwall Unified Client that is supposed to install itself to the PC, and Intune reports it is installing, but I can't see any actual software running in the system tray, so I'm not sure what I'm supposed to be looking for?

[tom_newton]

Hmm, and you are seeing the on-prem blockpage still?

[Ironside]

So some traffic is authenticating itself as the user without being prompted, but some traffic is remaining listed as an IP in the web filter logs. The cloud filter extension is reporting "Provisioning failed: No response from native client." but the configuration seems right on the script. 

The real concern is that authentication is inconsistent and sometimes resulting in teachers getting treat as staff, and student traffic getting listed on ip addresses rather than usernames.

Is there meant to be a difference between on-prem block page and cloud filter block page? We haven't noticed a difference before so I'm guessing the on-prem is still in place.

We're in a transition from all on-prem, MECM pxe booting and group policy managing our PCs towards autopilot and Intune managing our PCs. We just want to ensure that our Intune pcs still authenticate the users the same as our on-prem pcs.

[tom_newton]

OK, so it sounds like your cloud filter is not working at all because it is poorly provisioned. Did you push the corresponding MSI?

 

My suggestion is to contact your CS rep and have our install team help you roll ou CF more effectively.

[Ironside]

We've hammered out a issue with our ps1 script that was putting the wrong license and tenancy number as a reg key.

 

We now have the correct cloud filter block page, but now the cloud filter is failing to group users properly. Even though we have our Azure AD directory set up and with groups to assign the user as Staff, but it's registering the user as Default User.

 

In the Smoothwall Diagnostics, it's listing "Tenant" as "Unrecognised id (my_workplace's_actual_azure_tenancy)". Does the cloud filter pull the tenancy that the Azure AD user logged into on the PC, or is this caused by incorrect settings in the powershell script not being overwritten after we fixed the script? We originally thought the tenancy needed to be our Azure AD, not the Smoothwall tenancy.

Is there a way to purge the registry keys and redo them with a powershell script?

[Ironside]

Ok, my manager has made a lot of progress here and got the extension working, and things are going to the cloud filter now, properly, but a lot of ip addresses are being seen in the usernames rather than the username - is that standard when URLs are being accessed that aren't blocked or allowed by any categories?

[tom_newton]

that is possibly that your cf traffic is still going via on-prem - if you configure "secret knock" the cf traffic can bypass on-prem, and there'll only be traffic with usernames