top of page
Search

SentinelOne Series: The SSO Workaround You’ll Actually Thank Me For

  • 2 hours ago
  • 3 min read
ree
Hey everyone!

Welcome back to another post in my SentinelOne series — if you haven’t checked out the earlier ones, I recommend scrolling back and giving them a read.

Today, I’m here to share something different — a real-world workaround that helped me fix an interesting SSO problem with SentinelOne.


---------------------------------------------------------------------------------------------------------

The Background

So here’s the situation. There are two kinds of SentinelOne setups you can find yourself in:


Scenario 1: You Own the SentinelOne Server

You’re the big boss here — you bought the SentinelOne server or have full global-level access on the console.You can create tenants, sites, roles, policies — the whole thing.

If you’re in this camp, this trick won’t apply to you (and you’ll soon see why). You already have the keys to the kingdom.


Scenario 2: You Don’t Have Global Access

Now this is where the magic happens.

Let’s say you don’t own the SentinelOne backend. Instead, you asked SentinelOne (or your MSSP) to create an account for you. So they set you up as a tenant on one of their servers, and you start deploying your client environments under your account.


Nothing complex so far — right? Easy stuff.

---------------------------------------------------------------------------------------------------------

The Challenge

Now imagine this — I’ve got a client who manages about seven of their own clients under my SentinelOne account, and here’s where things start getting interesting : each of those seven clients uses their own SSO (Single Sign-On) setup.


Sounds simple, right? But here’s the real issue


  • SentinelOne doesn’t make it easy to handle multiple SSO configurations under one parent structure.

  • If my client and his each client all have different identity providers (like Okta, Azure AD, Ping, etc.), things quickly become messy when it comes to access and visibility.

  • The client wants his IT team to access the specific client sites they’re responsible for —but they should not see the there Sentinel One site or endpoints that I (as the managed security provider) monitor and manage for them.



So the problem was clear:

How can I let their IT team log in through their own SSO, get to their client’s SentinelOne site, and still keep my internal SentinelOne environment completely hidden from them?

That’s where the workaround comes in. 😉



In short — you want separation between authentication and visibility.

---------------------------------------------------------------------------------------------------------

The Workaround I Used

Alright, here’s what I did (and honestly, it worked beautifully).

  1. Created a new site in SentinelOne called something like:

    👉 Cyberengage Auth Passthrough

    This site will have zero endpoints — it’s purely there to authenticate users through SSO.


  2. Configured SSO on this site.

  3. Deleted all local SentinelOne accounts for the managed IT users from the parent tenant. We don’t want anyone logging in locally anymore — SSO all the way.

  4. Then, had each Managed IT user log in via SSO to the new Auth Passthrough site.

  5. Once they were authenticated through that SSO site, I reassigned them roles for the client sites they actually needed access to.



And just like that… 🎯

  • Employees can’t see any endpoints of there site.

  • Managed IT can access the client sites they support.

  • Everyone uses SSO — clean and compliant.


---------------------------------------------------------------------------------------------------------


Why This Works

Think of it this way —I separated authentication (the SSO part) from data access (the endpoints).

The Auth Passthrough site acts as a secure door — people come through it, prove who they are via SSO, and then I decide which rooms (client sites) they can enter after that.


This setup keeps SentinelOne access organized, auditable, and most importantly — isolated per client.



---------------------------------------------------------------------------------------------------------

The End Result

✅ All users authenticate via SSO.

✅ No local accounts left to manage.

✅ Employees can’t see internal endpoints.

✅ Managed IT can view and manage the client monitoring I responsible for.

✅ No global-level permissions needed.


It’s a simple but powerful design when you’re operating inside someone else’s SentinelOne tenant and need a clear boundary between teams and clients.



---------------------------------------------------------------------------------------------------------

Final Thoughts

Sometimes SentinelOne setups aren’t one-size-fits-all — especially when you’re working under another organization’s infrastructure or managing multiple clients. You’ve got to be creative to make SSO, visibility, and role-based access all play nice together.


This workaround gave us that perfect balance.

If you’re struggling with multi-client SSO management in SentinelOne, try this approach — it might just save you a lot of headache (and support tickets 😉).

--------------------------------------------Dean-------------------------------------------------------



 
 
 
bottom of page