Zscaler Zpa Entra Id Integration
You set up a zscaler zpa entra id integration by linking both platforms with SAML and SCIM. This setup lets Microsoft Entra ID check user logins and sync group roles into Zscaler Private Access. Most platform teams start by adding the enterprise app from the Entra gallery. Then they exchange XML metadata files to establish trust between the two cloud services. Next, they map directory groups to network rules so engineers can reach private servers. If teams make these group rules too broad, users
Microsoft Entra ID (Azure AD): the complete guide
Architecture patterns, implementation strategies, and security best practices. Delivered to your inbox.
You set up a zscaler zpa entra id integration by linking both platforms with SAML and SCIM. This setup lets Microsoft Entra ID check user logins and sync group roles into Zscaler Private Access. Most platform teams start by adding the enterprise app from the Entra gallery. Then they exchange XML metadata files to establish trust between the two cloud services. Next, they map directory groups to network rules so engineers can reach private servers. If teams make these group rules too broad, users get wide network paths to sensitive databases.
How a zscaler zpa entra id integration works in practice
The link between Entra ID and ZPA relies on two main open standards. First, SAML handles the sign-in flow when a user opens their client app. ZPA redirects the user to Microsoft so Entra ID can check their password and MFA. When the login passes, Entra sends a signed SAML token back to the ZPA cloud. That token holds user attributes and group claims that tell ZPA who the person is.
Second, SCIM handles background user and group updates across both systems on a set schedule. Without SCIM, ZPA only learns about user changes when someone logs in with a new token. With SCIM turned on, Entra pushes new hires, role changes, and departures straight to ZPA. If HR removes a user in Entra, SCIM tells ZPA to cut their active sessions right away. Teams must check that attribute mappings match on both sides so group rules work right.
Why directory group sync is only the first step
Syncing Entra groups into ZPA solves the network routing problem for remote workers. It replaces legacy VPNs and stops you from exposing private server ports to the public internet. An engineer in the database group can only reach the specific host and port you allow. Conditional rules in Entra can also require a managed laptop before the user can log in.
Still, this setup only decides who can open a network path to a server. Once the tunnel is open, ZPA does not read the database queries or shell commands inside. Users still need a second set of local passwords or keys to log into the database. Teams often share these database logins, which ruins the clean audit trail from Entra ID. If an engineer runs a bad query, your network logs only show a TCP session. Also, raw query results can return live emails, phone numbers, card numbers, or national IDs. Group sync alone cannot rewrite matched fields in results or block a bad command in flight.
Microsoft Entra ID (Azure AD): architecture patterns and best practices
Continue reading? Get the full guide.
Free. No spam. Unsubscribe anytime.
Best practices for mapping roles and rules
To keep your setup clean, build small Entra groups based on specific job tasks. Do not give the whole engineering department one giant rule that reaches every production subnet. Split your app segments by tier, separating dev systems from live customer data stores. Test your SCIM sync in a small pilot group before you roll it out to everyone.
You should also watch your SAML signing certificates so they do not expire without warning. When a certificate expires, no one on your team can log into private tools. Set calendar alerts to rotate these keys during a quiet maintenance window. Finally, pair your network rules with deeper controls that check individual queries and commands.
Govern statements and responses across databases and APIs
Good config and scoped roles are needed setup. They do not check single queries in flight or mask sensitive fields in returned rows. Across Postgres, MySQL, SQL Server, MongoDB, ClickHouse, Kubernetes APIs, SSH, and internal HTTP endpoints, hoop.dev runs beside each supported service as an open-source proxy, a sidecar for your database or API.
First, hoop.dev guardrails block banned queries before they run. Then hoop.dev data masking rewrites matched sensitive values in responses in memory. The audit trail records every statement and verdict per resource. Furthermore, hoop.dev holds SOC 2 Type II and is open source on GitHub.
Frequently asked questions
What happens when you disable a user in Entra ID?
SCIM sends an update to ZPA within minutes of the change in Entra ID. ZPA then marks the user inactive and drops their open client tunnels right away.
Do users still need local database passwords with ZPA and Entra ID?
Yes, ZPA and Entra ID only check the user before opening the network path. The target server or database still asks for its own login credentials or SSH keys.
Why are my Entra ID groups not showing up in ZPA policy rules?
This usually happens when you do not assign the group to the enterprise app in Entra. Check your SCIM provisioning logs to confirm that group sync is turned on and running.