Zscaler - Provisioning & Authentication
In this article
User Provisioning and Authentication Methods in ZIA
Zscaler Internet Access (ZIA) supports several methods for provisioning users and authenticating them to the service. Both are prerequisites for granular security policy: without them, ZIA can only enforce policy by network location, with no visibility into which user, group, or department generated a request. Provisioning populates the ZIA service database with users, groups, and departments; authentication then lets ZIA recognize traffic as belonging to a specific identity, so policy and reporting can be built around location, department, group, or user.
This article covers the end-user authentication settings that govern how users prove their identity to ZIA, and walks through provisioning users, groups, and departments from the admin portal. This is distinct from how an administrator logs into the Zscaler console itself, which goes through the Zscaler Authentication Service (a two-step, Okta-style sign-in at console.zscaler.com supporting MFA and enterprise IdP integration). The settings below configure end-user authentication, not admin access to the console.
Authentication Methods
End-user authentication is configured under Administration > Authentication. The first decision is which user repository to use. The simplest is the hosted database, where users are added directly through the admin portal and stored, encrypted, in a database hosted by Zscaler. Hosted-database users default to password-based (form-based) authentication, with usernames, passwords, and attributes like group and department uploaded together.
Organizations that already maintain identities in Active Directory or OpenLDAP can instead configure one of those as the repository, under Administration > Identity Integration > External Identities, where a setup wizard handles initial and advanced configuration. For new deployments, the modern replacement for legacy on-premises AD/LDAP import tooling is the Zscaler Authentication Bridge (ZAB), also configured from External Identities.
For centralized identity and single sign-on, ZIA supports SAML, which Zscaler recommends as the preferred approach. Selecting SAML removes password-related settings from the menu and instead surfaces an option to add an identity provider.
Two further settings shape the sign-in experience. Authentication frequency controls how often users must re-authenticate (it does not apply to Zscaler Client Connector users); Zscaler recommends "only once," which authenticates the user once and sets a browser cookie lasting about two years, so users aren't reprompted unless they log out explicitly. Temporary authentication, disabled by default, lets an admin send a one-time token or link to a user or group — useful when a hosted-database user forgets a password. The token emails a temporary password for logging in and setting a new one; the link instead emails a page for setting a new password with a supplied temporary credential. Either can go to the user's company address or an alternate address on the user's profile.
Password and Login Settings
For hosted-database, form-based authentication, ZIA lets admins enforce a password strength policy: "None" applies no complexity requirement; "Medium" requires at least eight characters with at least one alphanumeric character; "Strong" requires a minimum of eight characters plus at least one digit, one capital letter, and one special character. Password expiration defaults to never, but Zscaler recommends setting an interval so hosted-database users rotate credentials periodically.
Admins can also force re-authentication for all users at once. Use this carefully, since it immediately logs out every user and requires them all to sign back in — most useful right after changing authentication configuration, to push every user onto the new settings immediately.
Provisioning Users, Groups, and Departments
Provisioning is managed under Administration > Authentication, using the separate Departments, User Groups, and Users pages. A new organization already has a default Service Admin department and group tied to its admin account.
Start with departments, since every user must belong to exactly one; create one by name (for example, a "Lab" department for a training environment) from the Departments page. Next, use User Groups to create groups — a user can belong to up to 128 of these. Groups can be added manually or in bulk via the sample CSV template, populated with group names and optional comments and then imported; a post-import summary reports records added, deleted, or errored.
One planning note: ZIA's Analytics reporting filters on users, departments, locations, and location groups, but not on groups. Where group-level report granularity matters, model that distinction with departments instead.
Finally, create users from the Users page. A manually added user needs a user ID (their email address), a username, one or more groups, a single department, and an initial password the user can change later. The temporary authentication email field only appears when one-time token or one-time link is selected for that user. Larger populations can be imported via CSV the same way as groups; if a CSV references a department or group that doesn't yet exist, ZIA creates it automatically. When re-importing to modify existing users, select the override option — without it, a file containing an already-existing username returns an error.
As with any authentication or user-data change, edits must be activated (Save, then Activate) before the Central Authority distributes them to the Public Service Edge.