ZDTA Certification Study Guide Notes

Zscaler Digital Transformation Administrator (ZDTA) Certification Study Guide Notes

How to Use This Study Guide

  • This study guide is designed to help you prepare for the ZDTA exam and certification.

About the ZDTA Exam

  • The Zscaler Digital Transformation Administrator (ZDTA) certification validates the knowledge required to design, install, configure, maintain, and troubleshoot Zero Trust Exchange implementations.
  • Exam Format:
    • Certification Name: Zscaler Digital Transformation Administrator (ZDTA)
    • Delivery Platform: Certiverse (online testing platform)
    • Exam Series: Zscaler Digital Transformation
    • Seat Time: 90 minutes
    • Number of Items: 50
    • Format: Multiple Choice, Scenarios with Graphics, and Matching
    • Languages: English
    • Exam Domain Weight (%):
      • Identity Services: 4
      • Basic Connectivity: 20
      • Platform Services: 15
      • Zscaler Digital Experience: 10
      • Access Control: 15
      • Cybersecurity Services: 20
      • Basic Data Protection: 16

Audience & Qualifications

  • The ZDTA exam is intended for Zscaler customers, sales engineers, and support personnel.
  • Candidates should possess:
    • A minimum of 5 years of experience in IT networks and cybersecurity.
    • A minimum of 1 year of hands-on experience with the Zscaler platform.

Skills Required

  • Ability to professionally design, implement, operate, and troubleshoot the Zscaler platform
  • Ability to adapt legacy on-premises technologies and legacy hub-and-spoke network designs to modern cloud architectures

Recommended Training

  • Zscaler recommends attending the Zscaler for Users (EDU-200) course and hands-on lab or having solid hands-on experience with ZIA, ZPA, and ZDX.

Core Skills

The core skills necessary for the ZDTA exam are:

  • Identity Services
  • Basic Connectivity
  • Platform Services
  • Zscaler Digital Experience
  • Access Control
  • Cybersecurity Services
  • Basic Data Protection
Identity Services
  • Identity integration focuses on authenticating users to the Zero Trust Exchange and consuming user attributes for policy enforcement.
  • Key capabilities:
    1. Understanding authentication mechanisms and their integration with Zscaler.
    2. Configuring Zscaler Identity Integration services and capabilities.
Authentication and Authorization to the Zero Trust Exchange
  • The initial step in connecting to the Zero Trust Exchange is verifying identity and context, along with consuming attributes for policy enforcement.
  • Typically, this involves connecting to a SAML identity provider (IdP), but Zscaler Internet Access supports other methods like LDAP or a hosted database.
  • Once user context is established, risk is managed through inspection and data protection, and policies such as Allow, Block, Isolate, and Prioritize are enforced.
  • Zscaler Internet Access covers SaaS and internet applications, while Zscaler Private Access configures connectivity to private applications and resources hosted in various environments.
  • Identity integration supports SAML or LDAP authentication with customer directories, enabling policy application based on identity and device posture, along with logging and reporting on access activity.
  • This allows for per-user and per-device-based URL filtering, application segmentation, tenant restrictions, and adaptive access to private applications.
  • Zscaler integrates with various identity management partners, including Active Directory, Azure Active Directory, ADFS, Okta, Ping, and any SAML 2.0-compliant identity provider.
  • The following sections cover configuring SAML and SCIM for Zscaler Internet Access and Zscaler Private Access.
SAML Authentication
  • SAML is a mechanism for federating identities between an identity store and applications, providing Single Sign-On (SSO) for users.
  • If a user is signed into the Identity Provider (IdP), they can access applications transparently without reauthentication.
  • SAML also enables the exchange of credentials across key components:
    • Service Provider (SP):
      • The "Application," also known as the Relying Party (RP) to the Identity Provider (IdP).
      • Employs the services of an IdP for the Authentication and Authorization of users.
      • Zscaler acts as a SAML SP.
    • Identity Provider (IdP):
      • Authenticates Users/Devices.
      • Provides Identifiers and Identity Assertions for users that wish to access a service.
      • Examples include Okta, Ping, AD FS, Azure AD.
    • Security Assertions:
      • Also known as Tokens.
      • Issued to users by the IdP.
      • Presented to SPs / RPs to confirm authentication.
      • Trust based on PKI.
      • Assertions may contain: Authentication, Attribute, or Authorization statements.
  • SAML Authentication Workflow:
    1. A user requests an application.
    2. The user, not yet authenticated, is redirected to Zscaler Internet Access or Zscaler Private Access.
    3. Zscaler, in turn, sends a SAML authentication request to the SAML identity provider (IdP).
    4. The IdP challenges the user to authenticate.
    5. The IdP retrieves additional user attributes and group memberships, including them in the SAML assertion.
    6. The IdP assembles the SAML assertion and cryptographically secures it using a digital signature.
    7. The SAML assertion is delivered to Zscaler via the user's browser using a form POST.
    8. Zscaler validates the digital signature to ensure it originates from a trusted source and that the data hasn't been tampered with.
    9. If verified, Zscaler issues an authentication token to the Zscaler Client Connector or a cookie to the user's browser.
    10. The user is authenticated at Zscaler, and the request for the application resumes via the Zscaler Zero Trust Exchange.
SCIM Authorization
  • SCIM (System for Cross-domain Identity Management) handles authorization and revokes access for disabled users.
  • It automates the exchange of user identity information between identity domains, providing automatically-driven updates to user attributes when changes occur in the home directory.
  • SCIM supports the addition, deletion, and updating of users, as well as applying policies based on user or group attributes.
  • Resource Model:
    • A standard schema is used for defining resources (e.g., users, groups).
    • Complex resource types are supported (e.g., with attributes, sub-attributes, multivalued attributes).
    • Resources are encoded as SCIM objects in JSON.
    • Zscaler recommends using SCIM provisioning whenever possible.
  • REST API - Operations:
    • Create: Add a resource (e.g., user, group).
    • Read: Get information about a resource.
    • Update: Update the attributes of a resource.
    • Delete: Remove a resource.
    • SSO: Trigger create/update to a third party.
    • Replace: Change a resource.
    • Search: Find a resource.
    • Bulk: Operations on multiple resources.
SAML Attributes vs. SCIM Attributes:
  • SAML Attributes:
    • Static
    • Only applied on authentication
    • Only changed on reauthentication
    • Can include device and authentication attributes
  • SCIM Attributes:
    • Dynamic
    • User- and group-specific
    • Updated after a change in the source directory
    • Frequency is IdP controlled
Advantages and Disadvantages of SCIM
  • Advantages:
    • Updates information automatically via API in real-time.
    • Allows users to be deleted.
  • Disadvantages:
    • Not supported by all IdPs.
ZPA Support for SCIM 2.0 Operations Supported
  • Add Users: As they are assigned to the ZPA SP in the source IDP
  • Delete Users: Remove ZPA access for users that are either removed from the ZPA SP in the source IdP or removed from the directory completely.
  • Update Users: Update SCIM attributes dynamically (e.g., group memberships)
  • Apply Policy: Based on SCIM user or group attributes.
SCIM Data Management
  • With SCIM enabled, read-only lists are created in ZPA for:
    • SCIM users
    • SCIM groups
    • SCIM attributes
  • Users can only be managed in the source directory/IdP
  • Users, groups, and attributes are updated from the source directory as changes are made.
SCIM Synchronization
  • Synchronization happens periodically using the API
    • Update interval of ~40 minutes
    • Manually triggered at any time
  • Updates are queued for sync from the IdP when:
    • Users are added/removed to/from a group mapped to the ZPA SP
    • Users are individually assigned to or removed from the ZPA SP
    • Users are removed from the source directory entirely.
    • User attributes are changed in the source directory.
Basic Connectivity
  • This section covers the mechanisms to connect to the Zero Trust Exchange, depending on the use cases and locations.
  • Key Outcomes:
    1. Identify how zero trust components are established in the cloud.
    2. Recognize the connectivity services Zscaler uses to securely connect users and applications to the Zero Trust Exchange.
    3. Discover how to configure Zscaler connectivity control services and capabilities.
  • Key components:
    • Zscaler Client Connector
    • App Connectors
    • Browser Access & Privileged Remote Access
Connecting to the Zero Trust Exchange (ZTE)
  • Zero trust components are established in the cloud.
  • Users/devices, IoT/OT devices, or workloads must establish a connection to this cloud for security controls to be enforced.
  • Zero trust connections are independent of any network for control or trust.
  • Access is granted without sharing the network between the originator and the destination application.
  • The network serves as the means of connecting initiators to destination apps.
Zscaler Client Connector
  • The Zscaler Client Connector is a lightweight app that sits on users' endpoints and enforces security policies and access controls regardless of device, location, or application.
  • It creates a tunnel to the Zero Trust Exchange for the protection of SaaS and internet-bound traffic.
  • It provides a persistent control plane and dynamic, micro-segmented data plane tunnels to the ZTE for internal app protection.
  • Traffic is delivered to the application via an outbound-only data plane tunnel from the Zscaler App Connector.
  • Key Features:
    • Consistent Experience on all Platforms
    • Strict Enforcement Options (Tamper Proof)
    • Simple Enrollment
    • Trusted Network Detection
    • User Attribution and Asset Identification
    • Transparent Authentication for Users
    • Install Zscaler or Custom SSL Inspection Certificate
Authenticated Tunnels
  • The client connector forwards traffic to Zscaler Internet Access, where the recommended mechanism is to use the Zscaler tunnel.
  • The tunnel-based approach intercepts traffic at the network level and forwards that traffic through an encapsulated tunnel to the Zscaler platform.
  • Authenticated Tunnel Options:
    • ZTunnel - Packet Filter Based
      • Creates packet filters (Windows Only) that steer traffic toward the Zscaler Client Connector process.
    • ZTunnel - Route-Based
      • Creates route table entries, using an additional network adapter as the route for traffic.
    • ZTunnel with Local Proxy
      • Deploys a system proxy to localhost and tunnels traffic toward the Zscaler cloud.
  • Additional options for legacy implementations:
    • Enforced PAC mode. instruments the PAC file in the browser.
    • None: Relies on the group policy object or the default configuration within the browser.
ZTunnel 1.0 vs. 2.0
  • Tunnel modes come in two formats: Legacy Z-Tunnel 1.0 and modern ZTunnel 2.0.
    • ZTunnel 1.0:
      • An HTTP CONNECT tunnel.
      • Does not really encapsulate the traffic; simply adds header information.
      • Has two tunnels: one for authentication, enrollment, and passing traffic, and another for policy updates.
      • Attributes:
        • 80 / 443 Proxy Aware Traffic Only
        • No Real Encapsulation of Traffic
        • No Control Channel
        • Limited Log Visibility
        • No Visibility Into Non-Web Traffic
        • Configurable drop of Non-Web Traffic
    • ZTunnel 2.0:
      • DTLS (Datagram Transport Layer Security) tunnel with fallback to TLS (Transport Layer Security), supporting all client traffic.
      • The Zscaler Firewall inspects and applies policy on all traffic.
      • A single tunnel from the client to the Zero Trust Exchange.
      • Notifications from the Client Connector admin portal are passed through the Zero Trust Exchange directly to the client in real-time.
      • Attributes:
        • Any TCP, UDP, and ICMP Traffic
        • DTLS runs on UDP = Faster Transport
        • If the client detects that the DTLS tunnel wasn't successful, such as a firewall blocking UDP traffic, we want to fall back to a TLS-TCP connection.
        • DTLS uses a TLS tunnel = Integrity Tunnel
        • Provides Control Channel = updates to client (policy changes), available updates, connectivity information, and logging/alerting towards the client.
        • Logging of Client Connector Version, ZTunnel version…
        • Tunnel Failure: connection timeout options and additional options for redirecting traffic to a local listener (tunnel with local proxy, providing safe fallback within the client if the tunnel mode connection is not successful.
Forwarding Profile: Trusted Network Detection
  • Trusted network detection determines if a user is in the office, branch, data center, or similar locations based on certain criteria.
  • Criteria:
    • Hostname and IP: Check if a specific FQDN resolves to an IP address.
    • DNS Search Domains: Check if the DNS search domain (provided by DHCP) matches the configuration.
    • DNS Server: Check if the DNS server (provided by DHCP) matches the configuration.
  • Combining these, you can identify if the user or device is on a trusted network, enabling decisions on how forwarding mechanisms are used.
  • Forwarding profiles can reference multiple trusted networks.
Forwarding Profile: Profile Action for ZIA
  • Select trusted network criteria and choose from a list of predefined trusted networks to apply the forwarding profile.
  • For a device on a trusted network, you can decide to tunnel traffic, use a tunnel with a local proxy, enforce the proxy, or do 'none'.
  • Best practice: Use tunnel mode, specifically ZTunnel 2.0, which captures all traffic within the client and tunnels it to Zscaler within a DTLS tunnel.
  • With the ZTunnel 2.0 configuration, default to DTLS, with the ability to fall back to TLS as necessary.
Forwarding Profile: System Proxy Settings
  • Control how the browser (or more specifically the operating system) receives proxy settings.
  • If migrating from an on-premises proxy, you likely have existing proxy settings.
  • Recommendation: Enforce a no-proxy configuration with tunnel mode.
  • Enforcing Proxy Action Type options:
    • Automatically Detect Settings: The client sends a WPAD (Web Proxy Auto-Discovery) lookup looking for a proxy.
    • Use Automatic Configuration Script: Explicitly configure where the Zscaler Client Connector sets your custom system PAC file to download and run through that PAC file configuration for traffic to be explicitly proxied to a proxy server. Also referred to as a forwarding PAC file.
    • Use Proxy Server for Your LAN: A hard-coded proxy import (IP address and a port or an FQDN and a port) with the ability to bypass local addresses.
    • Execute GPO Update: The Windows machine will provide a GPO (Group Policy Object) update/force from Active Directory to set the proxy settings on the machine.
Understanding the distinction between a forwarding PAC and how the forwarding PAC is implemented within Zscaler Client Connector
  • With a tunnel mode configuration, do not set any forwarding PAC file.
  • Have the client intercept the traffic natively as the browser or the client configuration resolves an internet address and intercepts the traffic as it routes toward the internet and tunnels it toward the Zero Trust Exchange through the DTLS tunnels.
Application Profile
  • The application profile maps forwarding profiles to different users and devices based on specific criteria.
  • Configure a specific application profile for Windows, Mac, iOS, Android, and Linux devices.
  • The app profile selects the forwarding profile, which defines the method of tunneling.
  • It also defines the on- and off-trusted network configuration and ensures the system proxy is not configured.
  • The app profile PAC URL defines the Zero Trust Exchange node to be used based on the client's geographic IP information.
  • Common configuration items include:
    • Custom PAC URL: References the PAC file configured in the ZIA Admin Portal, making decisions on traffic that should be forwarded or bypassed from the Zero Trust Exchange.
    • Override WPAD: Ensures that the system GPO WPAD configuration is prevented and that the WPAD configuration in the forwarding profile is used as precedence.
    • Restart WinHTTP specific to Windows devices: Ensures that the system refreshes all of the proxy configuration once Zscaler Client Connector is established.
    • Install Zscaler SSL Certificate: Covered more in-depth in the next section; simply uses the one provided by Zscaler if you aren’t pushing out your own certificates from your own Certificate Authority.
    • Tunnel Internal Client Connector Traffic
    • Ensures that the health updates and policy traffic passes through the Zscaler tunnels towards the Zero Trust Exchange
    • Cache System Proxy
    • Ensures that the software can uninstall or revert to a previous version and that the end user will maintain business continuity
Deploying Zscaler SSL Inspection Certificates
  • A critical part of the Zero Trust Exchange is the ability to inspect SSL.
  • It's important that the client trusts the SSL certificates used for SSL inspection.
  • Zscaler Client Connector can deploy the Zscaler root CA as well as custom root CA used within an organization.
  • The app profile can also ensure that the SSL certificate is installed.
Tunnel 2.0 Configuration
  • Specific application bypasses for UCaaS, like Microsoft Teams or Zoom, can be configured under application bypass.
  • Make exclusions and inclusions for traffic to grab at the adapter level and pass into the Z-Tunnel 2.0.
  • Exclusions and inclusions of DNS requests are also configurable.
  • DNS requests are tunneled to the Zscaler cloud, where the Zscaler cloud performs the DNS resolution.
Forwarding Profile PAC vs App Profile PAC
  • Forwarding Profile PAC:
    • Steers traffic toward or away from the Client Connector
    • Controls System PAC file - which HTTP Proxy to be used for a URL, tunnel with local proxy or other explicit proxy.
    • Has no bearing where Client Connector will route traffic, only where the user’s apps will send traffic."