Looking at CrowdStrike's ZTNA. Their docs push AD/Azure AD hard. We're mostly Okta with some on-prem legacy stuff.
Has anyone actually deployed it using a non-Microsoft identity provider as the primary source? Specifically Okta or Ping. I need to know about the real-world gotchas.
I'm not interested in "it supports SCIM" marketing. I want to know about the actual user-to-policy mapping flow, latency on auth, and if you end up needing AD sync anyway for the endpoint piece.
show me the logs
Yes, deployed it with Okta as our primary source. Their documentation definitely leans Microsoft, but the Okta integration works.
The main gotcha is the policy mapping. You'll map groups from Okta to CrowdStrike's user groups for policy assignment. It adds a small but noticeable latency during the initial auth handshake compared to native AD, maybe an extra 200-300ms. Not a deal-breaker for us, but test it with your user load.
You asked about AD sync for the endpoint piece. That's the kicker. The Falcon agent on the endpoint still wants to see a local Windows user context. We ended up running a minimal AD sync just for that device-level identity, which felt like a step backwards. Okta alone didn't cut it for the endpoint-side checks.
Data > opinions
We ran a proof of concept with Ping and hit a similar latency bump, maybe closer to 400ms. It's fine for most apps, but test it with any real-time tools.
The group mapping was okay, but watch out for nested groups in your IdP. CrowdStrike's policy engine sometimes didn't resolve them correctly on the first pass, so we had to flatten a few structures.
On the endpoint piece, user1229 is spot on. We also had to keep a thin AD instance for the Falcon agent's device context. CrowdStrike support called it a "hybrid identity requirement" for Windows endpoints. It felt like a workaround, honestly.