Day 2 ZPA Bootcamp Slides - New Hire Version

Welcome To Day 2
ZPA Support/TAM Bootcamp Training 201

By: Davis Altamirano
Class Starts at 8:00 am PDT / 9:00 CDT / 11:00 am EDT
1 ©2021 Zscaler, Inc. All rights reserved. ZSCALER CONFIDENTIAL INFORMATION SECURING YOUR DIGITAL TRANSFORMATION
ZPA Traffic Flow
Module 2 Objectives
By the end of the module, you will be able to explain the ZPA traffic flow
and also locate the configuration option from the admin porta
Objectives
● Explain the traffic flow of ZPA connections with ZCC and browser access
● Explain the role of ZCC mtunnel
● Understand the use of dispatchers in the ZPA architecture
● understand how the ZCC contacts the ZPA broker
● Identify urls and hostnames used by ZCC and app connector when
connecting users with internal applications
● Describe the different functionalities of Admin portal.
ZPA Traffic Flow Overview
ZPA Traffic Flow Overview (Client Connector)
● ZCC establishes a single persistent tunnel to the geographically closest Broker.
● ZCC resolves any.broker.prod.zpath.net to find it’s nearest broker
● ZAPP issues an internal application request. This “microtunnel” goes to the Broker.
● The Connector creates an outbound tunnel to the same Broker, which “brokers” the link.
ZPA Traffic Flow Overview (Dispatcher end to end)
● When ZCC issues an mtunnel request, the Broker performs policy analysis.
● If the connection is allowed, the Broker asks Dispatcher to choose a Connector from all,
● Control Brokers that have health data on the application.
ZPA Traffic Flow Overview(Browser Access)
Lifecycle Of A Resource Request
Understanding ZPA Internal Application Requests
• Connector authentication:
• Verifies enrollment and status of the zpa process
• Opens a control and a configuration connection to co2br.prod.zpath.net (resolved to the
broker closest to the DNS server)
• Fetches configuration from the broker (config and control connections could go to diff
brokers)
• Connector knows the application domains/IPs that could be accessed through it
Continuing with the Flow
• Application registration:
• Connector registers applications periodically(every 5 minutes) through the control
connection (will redo it for any new control connections to other brokers)
• Based on the application ID assigned to these applications, a dispatcher pool is selected
and ZPA SE forwards the application registration to the entire pool
• The dispatchers now know the application IDs reachable through these connectors and
the ZPA SE through which the connectors are accessible.
• Zapp startup:
• verifies enrollment
• connects to broker.prod.zpath.net (resolved to the broker closest to the DNS server)
• SAML assertion from the enrollment or last reauthentication is sent to the broker
• if the assertion is too old, reauth is requested. Or else, ZPA leans the attributes of the user
from the assertion
• Broker sends list of resources available to that user
Client Forwarding Policy
• The ability to have multiple independent trusted defined networks for use with a companies use
case.
• They would want to have different “corporate networks” that have apps bypassed only when on
“Corp Net A” and not on “Corp Net B”.
• This would allow a company to share and limit resources between the two organizations after a
M&A or even within the same company.
• When Trusted Network criteria is matching for some interface other than Physical it should be
mapped as Trusted
• Based on this CFP the App Segments are downloaded on the ZCC.
• Resource request:
• DNS request is intercepted by the Zapp if the domain is accessible in the
configuration and Zapp sends a DNS check for the domain in question
• ZPA SE checks the dispatcher pool for the application ID and forwards
the DNS check to the nearest dispatcher
• Dispatcher checks its DNS cache. If resource not found, forwards it to all
the connectors through the right ZPA SE.
• Each connector checks its DNS cache. If not found, performs a local DNS
resolution and returns the result to the ZPA SE that proxied the check.
• ZPA SE forwards it to all the dispatchers in the pool who store it in DNS
cache and the nearest dispatcher sends the response back to the ZPA
SE closest to the Zapp.
• ZPA SE forwards the response to Zapp.
• Synthetic IP allocation and LW filters:
• Zapp assigns a synthetic IP and inserts a filter for the IP in the system's table.
• Zapp acts as proxy for any subsequent connection to this resource.
• Zapp requests a mtunnel to the application in question. (mtunnel ID is a 32-bit tag)
• ZPA SE buffers the data received on the ztunnel until the mtunnel is established. This is
similar to the trickling process used in ZIA.
• Once the mtunnel is complete, the data from tcp stream is proxied in both directions.
DNS Request Interception and Broker Check
2020-01-10 21:46:02.808680(-0800)[46972:606604] INF DNS: QRY=A(1), Name=noc2.zscaler.com
2020-01-10 21:46:02.808721(-0800)[46972:606604] INF DNS: Domain: noc2.zscaler.com is never bypass domain.
2020-01-10 21:46:02.808754(-0800)[46972:606604] DBG DNS: ZPN Domain=noc2.zscaler.com State=lookup pending (2) TTL: 180
2020-01-10 21:46:02.808771(-0800)[46972:606604] DBG DNS: Domain=noc2.zscaler.com is ZPN!
2020-01-10 21:46:02.808785(-0800)[46972:606604] DBG DNS: Check ZPN domain=noc2.zscaler.com with broker
2020-01-10 21:46:02.808814(-0800)[46972:606604] INF Send DNS request to broker. Size: 92 Data: { "zpn_dns_client_check" : { "id" : 4, "name" : "noc2.zscaler.com", "type" : "A" } }
DNS Check Response from Broker

2020-01-10 21:46:02.808814(-0800)[46972:606604] INF Send DNS request to broker. Size: 92 Data: { "zpn_dns_client_check" : { "id" : 4, "name" : "noc2.zscaler.com", "type" : "A" } }
2020-01-10 21:46:02.824708(-0800)[46972:606616] INF ZPN: Control Message Response Data: {"zpn_dns_client_check":{"id":4,"name":"noc2.zscaler.com","type":"A"}}
2020-01-10 21:46:02.824764(-0800)[46972:606616] DBG DNS: ZPN Response id=4 , Query type: 1, Target Name=noc2.zscaler.com. (len=18) Response Time: 0.01586 seconds
2020-01-10 21:46:02.824792(-0800)[46972:606616] DBG DNS: ZPN Domain=noc2.zscaler.com State=zpn valid (513) TTL: 180
Application learning:
- ZPA SE allocates a cryptographically random, unique mtunnel id for every connection to a unique
domain.
- ZPA SE performs policy check and logs the allow/deny.
- if successful, ZPA SE forwards the mtunnel request to the nearest dispatcher(latency and
availability) based on the application ID.
- dispatcher checks to see if it knows how to reach the application. If not, sends an 'application
being learned' message to the ZPA SE.
- dispatcher sends application discovery request to all connectors responsible for the wildcard.
- connectors discover the server IPs for the application using DNS. Performs reachability check for
all server IPs and will continue to do so for 30 minutes after every access attempt.
- all connectors individually report the information for all server IPs back to the ZPA SE, which
forwards this health message to all dispatchers in the pool.
- All the dispatchers know the optimal paths and maintain the state for 30 minutes of idle time.
How Brokers Communicate with Dispatchers
Every Broker in a ZPA cloud environment actively maintains TLS connections with every Dispatcher
in its cloud.
The screenshot below comes from a single Broker in the production ZPA cloud.
The phrase near the end of every line, "fohh_connection_connected", indicates an active and
mutually-authenticated TLS session. This single broker is connected to all available Dispatchers.
The same is true of every Broker in the cloud.
Therefore, the communications path between one Broker and the upstream Dispatchers looks like this:
ZPA establishes a full mesh from Brokers to Dispatchers. The end result is something like this:
Dispatchers do not communicate with one another.

Dispatchers communicate only with Brokers.
Mtunnel creation:
• The first ZPA SE resends the mtunnel request to the same dispatcher.
• The dispatcher chooses a path based on: 1. lowest latency 2. round robin 3. user
stickiness cache
• The dispatcher forwards the mtunnel request for the application on a specific server
IP to the chosen connector through the right ZPA SE.
• Connection setup:
• Connector creates a connection the specified server IP on the specified port.
• Connector opens a data connection to the ZPA SE to which Zapp is connected and
proxies the connection.
• Subsequently, connector sends a bind request to the same ZPA SE to bind the first piece
of mtunnel to this data tunnel.
• ZPA SE will perform the bind if the mtunnel id matches.
• Success state:
• Zapp has a synthetic IP for the domain and one mtunnel for it.
• One ZPA SE has an mtunnel connecting the Zapp and the connector.
• One ZPA connector has a fully connected mtunnel that passes the data.
• Both connectors know the health state(DNS, reachability) of the application and that they
should be monitoring it.
• All dispatchers know that the application is resolvable, all the paths and their corresponding
latency. And one dispatcher adds stickiness for the user to the application.
How ZAPP Contacts Brokers
● When a ZPA client (such as ZAPP) establishes its initial connection to the ZPA cloud, it will
contact the any.broker subdomain for that cloud. For example: the commercial production
cloud domain is prod.zpath.net, which makes the full FQDN any.broker.prod.zpath.net.
● The any.broker subdomain points to a special subset of Brokers classified as redirect
brokers, or rbrokers.
● These rbrokers track the location and load of all available brokers in the cloud. When the
client connects, the rbroker will determine the optimal Broker for that client, then issue a
redirection request. The redirection request is a strong suggestion for the client to connect to
that other Broker instead. (The client can choose to ignore the redirection request.)
● rbrokers will suggest the two geographically closest ZPA data centers to the ZAPP client, by
comparing:
● The geographic coordinates manually configured by ET Operations for that data center,
and the geographic coordinates provided by ZAPP.
● The redirection broker evaluates this data to choose two sites: a primary suggestion, and a
failover suggestion.
● For each site chosen, the redirection broker will provide the FQDN of the least-loaded broker
at that site. (If all brokers are at maximum capacity, the site isn't considered a viable
21 candidate for redirection, and a different site is used.)
©2021 Zscaler, Inc. All rights reserved. ZSCALER CONFIDENTIAL INFORMATION SECURING YOUR DIGITAL TRANSFORMATION
Example Broker Redirection for ZAPP
● Consider a ZAPP user in India,. ZAPP might receive the following two addresses:
● First choice: broker1.bom5.prod.zpath.net (The least-loaded broker in Mumbai, India)

● Second choice: broker2.bom5 (The least-loaded broker in Mumbai, India)
● If all brokers in India are at maximum capacity, then Bom5 is not considered a valid
candidate. Instead, ZAPP might receive:
● First choice: broker1.maa2 (The least-loaded broker in Chennai, India)
● Second choice: broker2.maa2 (The least-loaded broker in Chennai, India)
● In the ZAPP log, this message prints as a JSON object:
● {"zpn_broker_redirect":{
● "redirect_only":1,
● "brokers":["broker1.bom5.prod.zpath.net", "broker2.bom5.prod.zpath.net"],
● "shutdown_time":0,
● "timestamp_s":1563231357
● }}
Example Broker Redirection for ZAPP
Lab Exercise #1
See the ZPA flow in Action
• See the Traffic Flow on your corp network.

• See how the access to internal apps is working.
• Try to access the below sites with and without ZPA on ZCC enabled and see the difference.
• https://jira.corp.zscaler.com
• https://svn.corp.zscaler.com
• Try to resolve the above URLs with and without ZCC and see the difference.
• Find the below:

• IP for the Above URLs with and without ZCC
• Which URLs were accessible and which was not.
Break
Authentication
Authentication Mechanism We Support
User authentication to the platform
● Authentication with Zscaler

○Supported Authentication Methods
■SAML
■ ZPA supports only SAML based authentication
− It Supports SAML Auto-Provisioning and SCIM Provisioning.
Authentication - SAML
SAML Overview
Security Assertion Markup Language (SAML) 2.0 is a set of
specifications that provide various means for a user to be
identified to a Relying Party (RP) through the exchange of
assertions issued by an Identity Provider (IdP). It includes a
number of protocols, protocol bindings, and interoperability
profiles designed for different use cases.
-developed by the Security Services Technical Committee of
OASIS
-XML based framework
How SAML works
Major Components
• Service Provider
• Identity Provider
• Client
How SAML works cont.
Every organisation has a database of the user.
-Database is used by the identity provider
-Service provider is configured to trust the Identity
provider
How SAML works cont.
Service Provider Initiated SAML

Benefits of SAML
• Platform Neutrality
• Loose coupling of directories
• Improved online experience for end users
• Reduced administrative costs for Service Provider
• No TCP/UDP port needs to opened between SP and
IDP
Components of SAML
Assertions
Components of SAML
Elements of SAML
• Version
• ID
• IssueInstance
• Issuer
• Signature (optional)
• Subject (optional)
• Condition (optional)
• Advice (optional)
• AuthnStatement
• AttributeStatement
• Status
Zscaler and SAML
The Zscaler service can enforce web and firewall policies by location,
department, group, and user, and it can track Internet usage by location,
department and user. To leverage the ability to enforce granular policies and
the powerful reporting capabilities of the Zscaler service, provisioning and
authenticating users are required
SAML can be implement to provide Authentication so that Zscaler can Identify

the users and also can be used for provisioning for user forwarding additional
attributes such as Groups and Departments
Zscaler and SAML
Authentication Flow
User Auth SSO from Client to Cloud
Authentication Flow
SP Initiated Admin SSO
Authentication Flow
IDP Initiated Admin SSO
SAML Troubleshooting
• Collecting HTTP header traces from browser using developer tools or
Fiddler
SAML Troubleshooting
• SAML request/response are base64 encoded, we need to decode the date
to view SAML in plain XML format
Lab Exercise #2
ZPA Auth Setup/Review
• If ZPA Auth is already setup on your tenants, review the settings
• If ZPA Auth is not setup already then, proceed with the setup of Auth for both user and admin login
on the ZPA admin portal. You can set up an ADFS server in Azure or sign up for a dev Okta
account
• Login to your ZCC which has ZPA enabled and make sure auth is working.
• Login to portal using the admin login setup and make sure login is working
• Find the below:

• Logs in ZSATray and ZSATrayManager, which show the ZPA registration to be
successful.
• Help Portal Link for Okta and for ADFS

• HelpPortal Link : https://help.zscaler.com/zpa/configuring-idp-single-sign
Thank You
For Attending
Day 2

Day 2 ZPA Bootcamp Slides - New Hire Version

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Day 2 ZPA Bootcamp Slides - New Hire Version

Uploaded by

Copyright:

Available Formats

Welcome To Day 2

ZPA Support/TAM Bootcamp Training 201

DNS Check Response from Broker

How Brokers Communicate with Dispatchers

Dispatchers do not communicate with one another.

● First choice: broker1.bom5.prod.zpath.net (The least-loaded broker in Mumbai, India)

• See the Traffic Flow on your corp network.

• Find the below:

● Authentication with Zscaler

Service Provider Initiated SAML

SAML can be implement to provide Authentication so that Zscaler can Identify

• If ZPA Auth is already setup on your tenants, review the settings

• Find the below:

• Help Portal Link for Okta and for ADFS

You might also like