SentinelOne on macOS: When Its Own Default Profile Blocks Everyone Else
- 12 hours ago
- 2 min read
Dont forget to check out completle SentinelOne series
Introduction
Ran into something during a routine SentinelOne rollout that's worth sharing, because it doesn't look like a SentinelOne problem when you first see it — it looks like the third-party app is broken. An employee's VPN client wouldn't connect on their managed Mac. Install was clean, app opened fine, connection just sat on "establishing" forever. If you've deployed SentinelOne's default macOS configuration profile fleet-wide, you may be sitting on the same landmine without knowing it yet.
The Issue
The VPN app needs to register a macOS System Extension to function.
That registration was failing silently — no approval prompt, no actionable error, just a permanent hang at connect time.
Standard move for SentinelOne Users : disable the SentinelOne agent for a few minutes, have the user retest, see if the agent is the cause.
No change. Agent off, same failure.
That result normally clears SentinelOne — except this time it didn't, and the reason why is the actual finding here.
What I Found
The user checked the macOS System Extension policy database directly:
sudo plutil -p /Library/SystemExtensions/db.plist
It returned an active extensionPolicies entry scoped to one Team ID only:
"allowedTeamIDs" => [ "******" ] // SentinelOne's Team ID(Redacted)
"allowUserOverrides" => false
That policy did not change when the agent was disabled — which makes sense once you know how it's enforced:
MDM pushes SentinelOne's default macOS configuration profile, which includes a System Extension payload authorizing SentinelOne's own extension.
macOS writes that payload into /Library/SystemExtensions/db.plist as an extensionPolicies entry.
Once that entry declares an allowedTeamIDs array, macOS treats it as exclusive — anything not listed is denied at the OS level, silently, with no user prompt.
The SentinelOne agent process has nothing to do with enforcement at that point.
Killing or disabling the agent doesn't touch the profile sitting on disk, so the block persists agent-on or agent-off.
So the "SentinelOne is broken" theory and the "SentinelOne isn't involved" theory were both half right: the running agent wasn't the problem, but a profile it shipped with was
The Fix
I left SentinelOne's default profile untouched and pushed a second, separate profile adding the VPN vendor's Team ID to the allowlist, with allowUserOverrides flipped back to true. One reboot later, the VPN connected on the first retry.
If You're Facing This
Third-party app with a system extension / kernel component silently fails to load on a SentinelOne-managed Mac — no prompt, no clear error
Disabling the SentinelOne agent doesn't fix it
Run sudo plutil -p /Library/SystemExtensions/db.plist and look for allowedTeamIDs
If it lists only SentinelOne's Team ID (******) with allowUserOverrides: false, that's your cause
Fix: a separate MDM profile allowlisting the blocked vendor's Team ID — don't edit SentinelOne's default profile directly
Final Thoughts
SentinelOne wasn't misbehaving — its default macOS profile did exactly what it was configured to do. The gap was on our side: we deployed that profile fleet-wide without reading the System Extension payload closely enough to notice it also locks out every other vendor. Worth a five-minute audit of your own profile before this shows up as a VPN, webcam, or remote-access ticket with no obvious cause.
Comments