Posted on 06-09-2022 06:12 AM
Lightspeed just released the newest version of filter agent that completely changes how it works based on Apple's system extensions. This is completely different from the way it worked before. If I were to update it via auto update it would give the users a number of permission prompts that they could decline. LS released some documentation for updating these permissions automatically via MDM but frankly the instructions are kind of confusing for a relative newb. Could one of you kind experts perhaps take a look at these instructions and boil down what I need to do? Thanks in advance!
Solved! Go to Solution.
Posted on 06-10-2022 09:03 AM
You'll want configuration profiles to install the ca.cer certificate (Certificate payload) and the deployment_jamf.plist (Application and Custom Settings payload). You will also want a profile for the System Extension to suppress the security prompts.
Scope the configuration profile(s), and then use a policy to install the 2 .PKGs.
The system extension was the bit I had to fiddle with the most to get correct, so I've included some screenshots from my JSS that might be helpful.
Posted on 06-09-2022 05:46 PM
It is very wordy. The process is not complicated, but there are a lot of pieces to making it work properly that have to be done in a certain order.
Basically, you need to create some new profiles that will pre-approve the network extension and socket filtering to suppress the permission prompts on devices, as outlined in steps 5 & 6 under MDM deployment in the guide that you linked.
5.) Configure Content Filter Payload
Jamf requires that the following Team ID and Bundle IDs are added as approved System Extensions. Jamf will also have you approve specific System Extension types. If this is the case, use the same information below to also approve these System Extensions with Network as the type.
6.) Configure Content Filter Payload
Jamf will want to configure a content filter payload to pre-approve the security prompts when the Network Extension asks to filter the device. Use the settings below when setting this up.
That's it for what's needed for the autoupdate to work successfully.
There is another consideration, however, that you will need to check on: the certificate utilized by Relay for filtering. The autoupdate will NOT renew the CA certificate used by Relay for filtering, so you will need to renew this certificate manually before the expiration date. You would use the create_deploy utility included on the SmartAgent.dmg that you can download from Relay to generate a new root CA and deploy to your fleet. By doing this, you will also need to re-deploy the necessary ETC files needed by the root CA. This can be done automatically with Lightspeed's new utility agent, also included on the .dmg. Please look at the Generate Certificate section of the documentation you linked for the steps on this.
Again, basically, you will use the create_deploy to generate the certificate and deployment files needed. Upload the new certificate to Jamf and deploy to fleet (this can be in a new profile deployed alongside your existing Relay certificate, the old one will be used until the other files are replaced and the services restarted). Upload the deployment_jamf.plist to a configuration profile, deploy to fleet. Once the profile is on the device, have a policy to install the LightSpeed utility agent. This will create the support files needed by the new CA, copy them to the ETC folder (overwriting the existing files), then restart the services to use the new files.
Test, test, test, and test some more to make sure everything works as intended before deploying anything to entire fleet.
Posted on 06-10-2022 08:44 AM
There are 3 main scenarios that need to be planned for:
With any of these methods, test, test, test, and test some more to make sure that Relay is filtering properly after each installation type BEFORE mass deploying to your entire fleet. I am still in the process of doing my testing, which I hope to have completed next week. Also, you may want to wait on 2.0.3 before updating your clients, since that has some fixes they are working on for twitter and amazon decryption.
Posted on 07-08-2022 06:13 AM
I'm confused as to which route would be better to go. Copy the /usr/local/etc files using composer and push it out.
Or
To push out the depoloyment_jamf.plist file and have a policy to Install the Lightspeed Utility Agent.pkg
Are there any major differences anyone has noticed to recommend one direction over another?
Posted on 07-08-2022 10:07 AM
Both methods worked for me. @jbisgett mentioned in his writeup that placing the files directly into /usr/local/etc required a restart, but we have one set already as part of our deployment policy so I don't know if that's actually required.
It could be argued that placing the files directly is safer in some way, because the .plist/Utility Agent method leaves the RSA private key visible in System Preferences/Profiles
Posted on 06-10-2022 08:48 AM
Ok, I've posted explanations three times now and each time the forum refuses to save my post. Please join the #lightspeed channel in MacAdmins Slack, there are lots of discussions there on how others are deploying the new agent.
Posted on 06-10-2022 11:15 AM
Could you let me know how to join this Slack channel?
Posted on 06-10-2022 09:03 AM
You'll want configuration profiles to install the ca.cer certificate (Certificate payload) and the deployment_jamf.plist (Application and Custom Settings payload). You will also want a profile for the System Extension to suppress the security prompts.
Scope the configuration profile(s), and then use a policy to install the 2 .PKGs.
The system extension was the bit I had to fiddle with the most to get correct, so I've included some screenshots from my JSS that might be helpful.
Posted on 06-10-2022 11:15 AM
Thank you! This helped. Successfully deployed.
Posted on 09-15-2022 07:05 AM
New info here regarding the error "The Team ID may not appear in both Allowed Team Identifiers and Allowed System Extensions"
Posted on 01-07-2023 04:26 PM
I'm running macOS Ventura 13.1 and there might have been a change with base64. When I executed the create_deploy script it failed with an error about base64 I found that I had to edit line 22 of the create_deploy file from this:
CONFIG_DATA=$( base64 "${CONFIG}" )
to this:
CONFIG_DATA=$( base64 -i "${CONFIG}" )
it requires the -i between base64 and ${CONFIG}
I saved the file and execute it for it to complete without errors.
Posted on 03-27-2023 10:32 AM
In our testing - going from 1.7.7 to 2.0.2 - a reboot is required. We are public school K-12 and found our students were unfiltered until a reboot had happened. Possibly our environment, but a reboot is always a good thing right? I added a Jamf Helper prompt to let end users know an update was coming and a reboot would happen.