SentinelOne AV Install

[edullum]

Good Morning jamf Nation,

We are rolling out SentinelOne agent to Macs. I have the policy set, but I need some assistance with "pre-approving" the SentinelOne Agent kernel extension. The S1 setup guide gives a parameter to enter in the policy:

Kext Bundle ID: com.sentinelone.sentinel-kext

Developer ID: 4AYE5J54KN

I just don't know where to put the parameter. I tried copying and pasting it into Execute Command under Files and Processes, but that change doesn't 'approve' the agent. Based on the log file, it looks like it's trying to run the parameter, but then fails?

Any ideas?

[awginger]

Hi @AMJAD, I have done it 2 ways. The first is a policy that installs the package and required files to a specification location and then using the Files and Processes payload to run the install command  

sentinelctl upgrade-pkg /<file_location>/<package_name>.pkg

The other way I have done it is to cache the installer and then a script to install, the script looks like 

#!/bin/bash
   echo "Creating S1 tenant token"
   sudo echo "<s1-token-code>" > /Library/Application\ Support/JAMF/Waiting\ Room/com.sentinelone.registration-token

   echo "Running S1 installer"
   sudo usr/sbin/installer -pkg "/Library/Application\ Support/JAMF/Waiting\ Room/<package_name.pkg>" -target /

[Espinosa]

Hey, the configuration profile works but I'm wondering is there a way to build a Smart Group that selects the Macs that have this config profile installed? I don't want to push the Sentinel One package without the config profile first.

Thanks!

[ooshnoo]

What scripts is everyone using? How you are getting the token installed?

[peterj]

These instructions worked perfectly for us.

Installing and Upgrading macOS Agent with Jamf

Agents: macOS 2.6+ Jamf is macOS software to build packages, manage inventory and images, and run remote updates. You can use Jamf, or other MDM software, to install the SentinelOne macOS Agent.
During the installation, you must add Agents to a Site with the Site Token. From version Grand Canyon SP4, you can use a Group Token during installation, instead of a Site Token, to add Agents directly to a static Group in a Site. Get the Group Token from one Site > one Group > Network > Group Info.
To get the Site Token:
1. In the sidebar, click Scope and select a scope.
Select one Site. If you are in any other scope, the Site Token does not show.
2. In the Network toolbar, click Packages.

1. In the Site Token section, click Copy.

To install with Jamf:
1. In the Network toolbar, click Packages.

1. Download the PKG of the macOS Agent version to install.
2. Launch Jamf and log in.

3. Create a configuration profile with these values in the Approved Kernel Extensions:
   Kext Bundle ID: com.sentinelone.sentinel-kext
   Developer ID: 4AYE5J54KN

4. Click Computer Management.

5. Add the SentinelOne Agent PKG file to Jamf.
6. Click Script and enter these lines, with your values for the Site or Group Token and package version:
7. sudo echo "token" > /Library/Application Support/JAMF/Waiting Room/com.sentinelone.registration-token sudo /usr/sbin/installer -pkg /Library/Application Support/JAMF/Waiting Room/Sentinel-Release-version.pkg -target /
8. Click Save.
9. In Computers > Policies.

10. Click Packages and change Action to Cache.

11. Click Scripts and change Priority to After.

12. Click Save.
    The Agent installs the next time the selected endpoints connect with Jamf.

[dugnl]

@edullum Having the exact same issues with 3.4 and 3.6. I previously put the package into composer and ran the token script in composer then created a package. 3.2.1 and the new 3.2.3 works perfectly still. You can run those via command line. As soon as you run 3.4 and 3.6 via command line, that same error and contact the software manufacturer occurs. I've got a ticket open with Sentinelone but so far they've been less than helpful. Only pointing me to webpages I've already read and saying make sure my kext file is correct. My stuff has worked since March 2019, but doesn't work with 3.4 or 3.6. They haven't said what is different about their installers.

[dugnl]

3.2.0, 3.2.1 and 3.2.6 (Jan 31st 2020 release date), will all work if the Kext is installed first, then you install the pkg as downloaded directly from sentinelone and then you do the token afterwards. If you run the pkg in terminal, it works.
My previously created composer pkg worked for these versions but not 3.4 or the 3.6 versions.

The old composer pkg, I copied the file to the /tmp folder. Then my post install said sudo /usr/sbin/installer -pkg /private/tmp/SentinelOne/Sentinel*.pkg

I then added the site token in that same pkg sudo /usr/local/bin/sentinelctl set registration-token --longtokenhere

Used this method for a year. This did not work with 3.4 and 3.6.

I piggybacked off awgingers post from October 29, 2019.

I copied the 3.6.1 pkg as downloaded from sentinelone to the /var/tmp folder. I then used textwrangler to create the "com.sentinelone.registration-token" file. The trick here, is it says a txt file. But when you save it into the same folder (in this case /var/tmp), you must not have it named with a .txt extensions. Remove the .txt from the end. It must only be named com.sentinelone.registeration-token.

Of course make sure your permissions are good to go. Then create your pkg in composer. This time the install will work. 3.4. and 3.6 requires the token to be a part of the install. 3.2.3, 3.2.1 and 3.2.0 and all earlier versions don't care if you put a token during the install. Those are all good to do afterwards.

Despite what sentinelone's instructions state, the way for 3.4 and 3.6 is to pkg together these files and not call them afterward. I didn't try peterjs solution.

[Neil_Kitt]

Still banging my head against a wall. I've tried the various solutions and haven't had any luck. Maybe I'm not understanding the entire process everyone else is using but why all of a sudden since 3.4 does the method I have been using for over a year just stop working? The policy I have been using is just a simple policy that includes the package for sentinelone and then a Files and Processes with an Execute Command "sentinelctl set registration-token -- enter your token here". Starting to really hate SentinelOne.

[victormazzei]

.

[cwaldrip]

I've got a package putting the S1 installer and its token file in a folder at /private/var/tmp/SentinelOne.
A post-install script then runs...
installer -pkg /private/var/tmp/SentinelOne/SentinelAgent_macos_v4_1_2_3143.pkg -target /
rm -rf /private/var/tmp/SentinelOne
It works fine from the pkg, and if I run the policy manually sudo jamf policy -id ####. But it never finishes in Self Service. The folder gets removed so I know it gets to that step. And I can see the kext installed.

Why would it hang in SS and run fine as a policy from CLI?

EDIT: I figured it out... The package I built was set to restart. I had restart if package requires it. But that was hanging it up... maybe because the S1 installer is still doing something. I've set "User Logged in Action" to restart (not if package requires it). 🤦🏼‍♂️

[#11]

Hi,

Do you guys experience that after sentinel one kext was pushed down to Mac devices is blocking some extentions on Mac like Tunnelbrick, parallel desktop for mac and some others? so the allow button disappeared.

Please advise

Thank you

Markie

[ooshnoo]

@zachriver24

we saw similar behavior. Updating S1 agent to v4.2.2 fixed it.

[M-Ahmed]

I have a question might be different though. I installed SentinelOne using JamF but the devices are not checking in with JamF. Any idea as to why. Any help is appreciated.