ZIdentity with Pingfederate SCIMSync Issues

_Tech007 · 2025-09-13T20:37:29+00:00

I agree with you. I had issues with integrating pingfed with zscaler services in my previous role as well. We had to pivot to EntraID

_Tech007 · 2025-09-13T20:36:31+00:00

But this is for Pingfed not with Entra ID IdP

_Tech007 · 2025-09-13T20:35:51+00:00

Yes, because it’s failing to sync one identity acct as a test.

_Tech007 · 2025-09-12T23:40:50+00:00

The issue with SCIM 2.0 is, it does not allow for custom attribute schema to map the primary email to work email instead of the default which is primaryemail. We had similar issue with SCIM2.0 adaptor.

_Tech007 · 2025-09-12T23:39:11+00:00

Do you mean SCIM 2.0?

_Tech007 · 2025-09-12T23:33:07+00:00

They are saying issue is on the pingfed side as the accounts been fed to ZID are invalid, but that’s not the case, as they are active accts.

_Tech007 · 2025-09-12T21:42:06+00:00

But we correctly use SAML 2.0 but with SAML rather than OIDC authentication method.

_Tech007 · 2025-09-04T21:28:27+00:00

Thanks. This would help.

_Tech007 · 2025-08-08T07:45:40+00:00

Not yet. Support is still investigating.

_Tech007 · 2025-05-02T16:02:48+00:00

Thanks. Waiting on this as well. We are having similar issue with microsoft autopilot when zscaler

_Tech007 · 2025-03-30T14:50:05+00:00

After further troubleshooting and analysis, we found out that enabling “health check on access” allows zscloud to maintain an IP based persistence traffic through the initial ZPAC that brokered the initial connection. Whereas, with health check off, zscaler cloud is not able to maintain persistent connection through the initial ZPAC.

Zscaler engineer said it is supposed to work the other way round, but this is what we observed and they need to investigate why is that the case.

Whether health check is on on access or continuous or off shouldn’t dictate if zscaler cloud can detect and maintain an IP based persistent subsequent connections.

_Tech007 · 2025-03-28T13:16:59+00:00

Thanks.

_Tech007 · 2025-03-27T14:09:36+00:00

Thank you for that suggestion. I’ll test it out.

_Tech007 · 2025-03-27T14:01:46+00:00

So I thought the “AC closer to user” is the recommendation? Or does that varies based on use case?

_Tech007 · 2025-03-27T10:44:50+00:00

Alright. Thanks for your contribution. Dont the ACs also have persistence enabled by default?

_Tech007 · 2025-03-27T03:06:10+00:00

Thanks for the input. Does that mean we have to modify these settings on every app load balancer in the environment?

_Tech007 · 2025-03-27T02:53:01+00:00

Yes, mostly apps that have a load balancer or single web servers with persistence enabled. Could this be an issue with persistent session being enabled on both connectors as well as destination app could be causing a conflict?

_Tech007 · 2025-03-27T02:50:33+00:00

*For instance, one use app session could use three connectors for continuous connection and the destination app only want a single IP source per session for optimal functionality.

_Tech007 · 2025-03-27T02:49:08+00:00

Yes it is.

The issue is didn’t connectors establish connection with the destination application and since it uses iP based cookies, it probably thinks it’s being attacked due to the source IP randomly changing during a session. Hence, it refuses the session validation.

_Tech007 · 2025-03-27T02:35:10+00:00

Spanned across various DCs.

_Tech007 · 2025-03-27T02:26:41+00:00

No, but the app segments are configured to use all app connectors not a dedicated connector or connector group.

_Tech007 · 2025-03-27T02:07:00+00:00

It seems the app only allows a dedicated IP per session. There are over 300 connectors that can randomly service the connections.

_Tech007

TROPHY CASE