How does Zscaler Kerberos authentication work?
The Zscaler service uses Kerberos cross-realm authentication, enabling clients from your organization’s domain to authenticate themselves to the Zscaler Enforcement Nodes (ZENs) in the Zscaler domain. Your organization and the Zscaler domain establish a one-way trust relationship based on a shared password, eliminating the need to upload and manage keytab files or to join the ZENs to your domain.
For an overview of Kerberos authentication, see About Kerberos Authentication.
The following diagram shows a simplified view of the authentication process after the trust relationship is established. Note the following:
- In the organization's domain, the Kerberos Key Distribution Center (KDC) is integrated in the domain controller on the Windows server.
- In the Zscaler domain, the Central Authority (CA) hosts the KDC.
- The user is logged in to the corporate domain.
- The user's browser used the default Kerberos PAC file to identify the primary ZEN.
- The user's browser sends the request to the ZEN. (HTTPS requests are also sent as HTTP CONNECT method requests to the ZEN.)
If the ZEN does not find a Zscaler cookie for the domain in the HTTP request, it issues a 407 Negotiate challenge.
- Because the user has already logged into the domain, the user has a session ticket for the domain controller. Using this session ticket, the client sends the domain controller an authentication request for the Zscaler service.
The domain controller issues a cross-realm ticket.
- The client sends the cross-realm ticket to the Zscaler KDC, which issues a ticket for the ZEN.
- The client sends the HTTP request with the proxy authorization header and ticket, which contains the client information.
The ZEN decrypts the ticket and after verifying the user name, sends the request to the web site.
As shown in the diagram, users authenticate themselves only once when they log in to the corporate domain. They do not need to log in separately to the Zscaler service. Additionally, the Zscaler service is able to identify users through the proxy authorization header. This allows the service to then apply user, group and department policies on FTP transactions and on HTTPS transactions without decrypting them.