BadgerPatrol

Devices > Networks > Certificates > Server Certificate Authority certificates Your issue is going to be, that if the Chromebooks can't connect to the network without the certificate, then how will they connect to the network to obtain the updated certificate? Ideally you would be generating and deploying the updated certificate before you switch over to using it.

From a quick investigation, it appears that the SafeSitesFilterBehavior policy being enabled is what is triggering the block - disabling that policy, or adding schoolcomms.com to the URLAllowlist policy (rather than a URLBlocklist exception edit - shows how long it's been since I actually looked in Google Admin, seeing as the Blocked URL exceptions is targeting the URLAllowlist policy) appears to get it working.

2949 is the secure/HTTPS version of IDex that was introduced in IDex v2; I believe it is only supported in Maiden. If you want to stop it, I think you should be able to disable it in the registry by setting HKLM\System\CurrentControlSet\Services\IDexAgent\Parameters\HTTPSComms to 0.

One approach I've used in the past (and I'm assuming would still work with 10/11) is to set a BITS throttling policy to prevent the clients from downloading the updates during the day.

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.

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.

In my experience, as long as the Smoothwall can match the username in the Accounting packet with a user in an existing directory (i.e. IDex, Azure AD, etc), then you don't need to use the specific RADIUS Accounting directory type. The main thing to check is that users are using the correct username format for the directory type (e.g. domain\username for IDex, username@domain for AAD).

I believe the last we heard was "Dev are aware, but it's not a priority."

Are you using the "Active Directory" type or "IDex Directory"? From my experience IDex v1 supports nested groups, but IDex v2 doesn't.