Authentication & deployment — who the user is, and how they get ZCC

Start here · understand the lesson before the detail

What you are learning

This lesson explains two connected but different jobs: authentication proves who the user is, while deployment puts Client Connector and the correct profiles on the device.

In plain English

SAML lets Zscaler rely on an enterprise identity provider such as Microsoft Entra ID or Okta. SCIM keeps users and groups synchronised. Client Connector deployment then gives the endpoint the forwarding and posture profiles needed for traffic steering.

Real example

A user can sign in successfully but receives the wrong web policy. Authentication worked; the issue may be a missing group claim or stale SCIM membership. Reinstalling Client Connector would treat the wrong layer.

Follow this flow

• The user requests a Zscaler-protected service.
• Zscaler redirects the browser to the identity provider.
• The identity provider authenticates the user and signs an assertion.
• Zscaler validates the assertion and maps groups.
• Client Connector receives the appropriate app, forwarding, and posture profiles.

Evidence to collect

• SAML assertion issuer, audience, and signature
• User and group mapping in Zscaler
• SCIM provisioning status
• Client Connector profile assignment

Common mistake to avoid

Do not confuse authentication with provisioning. SAML proves identity during sign-in; SCIM creates, updates, and disables directory objects. JIT-only designs can leave stale accounts when employees leave.

Key terms before you continue

IdPSystem that authenticates the user.

SAMLSigned identity exchange for SSO.

SCIMUser and group provisioning.

ZCC ProfileEndpoint configuration applied by Client Connector.

Why this lesson matters

Without identity, ZIA can only apply Location policy — the lowest-resolution control. Identity unlocks per-user, per-group, per-department policy: "engineers can access GitHub, marketing can't access Reddit, the CFO bypasses bandwidth caps." Identity is also what lets ZPA replace VPN — every per-app access decision is keyed on the user's IdP identity + group membership, not on a network port.

Getting auth wrong has loud failure modes: users see the wrong policy (security incident), or they hit a SAML loop (helpdesk floods), or new joiners can't log in for days (HR escalates). Auth is the spine — get it right once, everything downstream gets easier.

Three authentication methods — quick compare

If you're starting a fresh rollout in 2026, the answer is SAML. Hosted DB is for labs. Kerberos is legacy — don't introduce it now.

SAML — the assertion walkthrough

SAML feels mystical until you've walked one assertion. Then it's mechanical. Here's exactly what happens when a user types http://gateway.zscaler.net (the ZIA enforcement URL) into a fresh browser:

What's in a SAML assertion

The XML SAML Response payload is what makes auth actually mean something. Boiled down it carries:

• NameID — the user identifier (typically email, e.g. ram.dixit@techclick.in)
• Issuer — the IdP's URL (e.g. https://sts.windows.net/<tenant-id>/)
• AudienceRestriction — must match ZIA's EntityID, or ZIA rejects it
• NotBefore / NotOnOrAfter — assertion validity window (usually 5 min)
• AttributeStatement — the custom attributes you sent (groups, department, employee ID, etc.)
• Signature — X.509-signed by the IdP's private key

ZIA reads the AttributeStatement to map the user to groups / departments / policies. Get the attribute names wrong in the IdP config and group-based policies silently break.

Configuring Azure AD as the ZIA IdP — step-by-step

1. Enterprise Applications → New Application → Browse the gallery
2. Search "Zscaler" → "Zscaler ZIA - Service Provider" template
3. Single sign-on → SAML
4. Basic SAML Configuration:
   Identifier (Entity ID):  https://login.zscaler.net  (or your cloud)
   Reply URL (ACS):         https://login.zscaler.net/sfc_sso
   Sign on URL:             https://login.zscaler.net

5. User Attributes & Claims:
   - emailaddress  →  user.mail
   - displayname   →  user.displayname
   - department    →  user.department
   - memberOf      →  user.assignedroles  (or send groups as user.groups)

6. SAML Signing Certificate → Download Federation Metadata XML

7. Users and groups → assign the AD groups that should get Zscaler

8. In ZIA Admin Portal:
   Administration → Authentication → SAML →
   Upload IdP Metadata XML → Auto-Provisioning ON
   → Save → Activate

Modern path: use the Federation Metadata URL instead of uploading static XML. In Azure AD, the URL is https://login.microsoftonline.com/{tenant}/federationmetadata/2007-06/federationmetadata.xml (Okta and Ping have equivalent URLs). Paste that URL into ZIA's SAML config — ZIA polls it on a schedule and auto-rotates the IdP signing cert. Eliminates the "old cert in metadata → SAML loop on Monday morning" failure entirely, which is otherwise the #1 SAML incident pattern.

SCIM provisioning vs JIT — pick one

When a user appears in Azure AD, how do they appear in ZIA? Two answers:

• JIT (Just-In-Time) — the user is created in ZIA's internal DB the first time they log in via SAML. Group attributes from the assertion populate their ZIA profile.
• SCIM — Azure AD pushes user + group changes to ZIA in real time via SCIM 2.0 (System for Cross-domain Identity Management). Users exist in ZIA before they ever log in.

SCIM is the production answer. JIT alone leaves dead accounts in your tenant when employees leave — both a security and licensing problem.

ZIdentity — the unified identity layer

ZIdentity is Zscaler's unified identity layer that sits between your IdP and all Zscaler products (ZIA, ZPA, ZDX, ZCC). As of late 2025 it's the default for new tenants and mandatory for new features like ZDX 2.0 and Branch Connector. Old SAML-per-app config still works for legacy tenants — but new builds should adopt ZIdentity from day 1. Without it, each product separately consumes the IdP (three SAML apps in Azure AD, three audit trails). With it, the IdP integrates once and ZIdentity brokers identity to every Zscaler product.

Practical reasons to enable ZIdentity:

• Single SAML setup in Azure AD instead of 2–3
• Unified group/role sync — one SCIM endpoint, not per-product
• Consistent posture context across ZIA and ZPA decisions
• Required for some newer Zscaler features (Branch Connector, ZCloud Connector with identity-aware rules)

ZCC enrollment — how the agent knows who you are

You can't have identity-bound forwarding (Lesson 3) without ZCC knowing who its user is. ZCC enrolment is what binds the local agent to a specific IdP identity. Two enrolment modes:

Mode A — Manual / user-driven

User downloads ZCC, opens it, types their email. ZCC redirects to your IdP login (SAML), user signs in, ZIdentity issues a long-lived enrolment token tied to that user. Token survives reboots, expires per policy (default 180 days; configurable 7–365 days in Administration → ZCC Portal → Enrollment).

Mode B — Auto-enrol via Intune / Jamf / SCCM (the production way)

Push ZCC via MDM with the enrolment payload baked in:

msiexec /i Zscaler-windows-3.x.msi /qn ^
  CLOUDNAME=zscalerthree.net ^
  POLICYTOKEN=<tenant-policy-token-from-ZCC-portal> ^
  USERDOMAIN=techclick.in ^
  HIDETRAY=0 ^
  STRICTENFORCEMENT=1 ^
  CLEANUNINSTALLPASSWORD=<long-random-string> ^
  LOGINPASSWORD=<uninstall-guard-password>

On first launch, ZCC reads the embedded policy token, contacts ZCC Portal, and silently exchanges the token for a SAML-backed enrolment using the logged-in Azure AD user. No user input. Zero help-desk tickets if the MDM payload is correct.

The mass-deployment SVG — fleet rollout in 3 lanes

Real-world scenario — SAML loop after Azure AD config change

Monday morning. The Azure AD team rotates the SAML signing certificate as part of their quarterly rotation. By 10:00 AM the help desk is on fire: "I keep getting redirected to Microsoft login and back to ZIA forever — infinite loop."

Diagnostic path:

1. Open one of the broken sessions in DevTools → Network. You see SAML POST → 302 → ZIA → redirect to IdP → POST → 302 → ZIA. Loop confirmed.
2. Check the SAMLResponse from the IdP — copy from network tab, decode the Base64 payload at samltool.com.
3. Notice the assertion is signed with a new cert (thumbprint changed). ZIA still has the old IdP cert in its metadata.
4. Fix: ZIA Admin Portal → Administration → Authentication → SAML → upload fresh IdP Metadata XML → Activate.
5. Validate one test user — login succeeds first try.

The full fix is <5 minutes once you've seen this pattern once. The lesson: when your IdP rotates certs, the SP must re-import metadata, full stop. Set a Slack/email alert from your IdP team when they rotate, and re-upload metadata the same day. (Even better: use the Federation Metadata URL — see the Pro Tip earlier — and ZIA auto-rotates.)

Exact error strings to grep for: in the IdP logs you'll typically see NotOnOrAfter condition violated (assertion came in after its expiry window) or NotBefore condition not yet met (SP clock is behind the IdP). Both point to clock skew or cert/metadata drift. Search those exact phrases in your SIEM during a SAML incident.

🔑 Lock in the key terms — tap to flip