Zscaler Architecture for

{customer_name}
Table of Contents
1 Executive Summary 4

1.1 Business Objectives 4

1.2 Zscaler Mission Critical Audit (ZMCA) Scorecard (Production Readiness) 4

2 ZPA Traffic Forwarding Use Cases 5

2.1 Roaming Users 5

2.2 Corporate Users 5

2.3 Traffic Sources 5

2.4 Zscaler Client Connector 5

2.4.1 Environment Prerequisites 5

2.4.2 Forwarding Profile(s) 5

2.4.3 Packaging and Rollout Guidelines 7

3 ZPA Certificates 8

4 Connectors and Server Groups configuration 8

4.1 Connectors 8

4.2 Servers and Server Groups 9

4.3 Connector Deployment Options 9

5 ZPA Authentication 9

6 ZPA Application Segment Configuration 10

6.1 Application Segments and Segment Groups 10

Subhead
date
 6.2 Browser Access 10

7 ZPA Policies Configuration 11

7.1 Access Policy 11

7.2 Timeout Policy 11

7.3 Posture Profiles Configuration 11

8 Log Streaming Service 12

9 Appendix A – Authentication with ZPA 12

10 Appendix B – Connector Overview and Deployment Requirements 13

10.1 Overview 13

10.2 Deployment Requirements 13

11 Appendix C – FAQ and Basic Troubleshooting 14

11.1 FAQ 14

11.2 Basic Troubleshooting 15

Subhead
date
Document Change Control
Date Changed Version Pages Changed Changed By

{{today}} 1.0 Initial Draft All {{Submitter_name}}

Sign-off
Name Role Position Date

Subhead
date
1 Executive Summary
1.1 Business Objectives ( List Business Objectives )

●
●
●
●

1.2 Zscaler Mission Critical Audit (ZMCA) Scorecard (Production Readiness)

ZMCA is a configuration audit performed by Zscaler, to ensure the most important configuration
options chosen by customers, align to Zscaler best practices. Zscaler provides this audit in the form of
a ZMCA Score card.

Area Priority Zscaler Recommended Configuration Current Status

Configuration

Traffic 1 Ensure ZCC processes are whitelisted and have access to all cloud To be verified
Forwarding hub IPs in ZPA cloud: (http://ips.<cloudname>.net/zscaler_app)

1 Ensure Firewall rules open from Connectors to all cloud hub IPs: To be verified
(http://ips.<cloudname>.net/zpa)

Resiliency 1 Minimum 2 Connectors per Connector Group To be verified

Service 1 Ensure connectors capacity requirements are met per connector To be verified
Performance sizing requirements

2 Connectors should be placed closest to the application servers To be verified

(example: same datacenter)

Service 1 Application segments based on FQDN rather than IP (example: To be verified

Availability *.int.company.com)

2 Connectors able to resolve internal, external and search domains. To be verified

Subhead
date
 2 For TCP/UDP applications, avoid ACL/FW between connector To be verified
and application server
For UDP applications, ensure connectors have ICMP access to
servers

2 If servers are statically defined; the health dashboard should show To be verified
reachability to all applications assigned.

Account = {{customer_name}} Overall Score: Met/Not Met

Audit Date = {{today}}

Subhead
date
2 ZPA Traffic Forwarding Use Cases
2.1 Roaming Users & Corporate Users

2.2 Traffic Sources

Traffic Source Package management Antivirus/FW software Scope

Windows {{WIN_PKG_MANAGEMENT_TOOL}} {{WIN_CLIENT_AV}} {{WIN_IN_SCOPE}}

MAC OS X {{MAC_PKG_MANAGEMENT_TOOL}} {{MAC_CLIENT_AV}} {{MAC_IN_SCOPE}}

Subhead
date
IOS {{IOS_PKG_MANAGEMENT_TOOL}} {{IOS_CLIENT_AV}} {{IOS_IN_SCOPE}}

Android {{ANDROID_PKG_MANAGEMENT_T {{ANDROID_CLIENT_AV} {{Android_IN_SCOPE}}

OOL}} }

Other {{zia_packet_mgmt_other}} {{zia_AntiVirus_other}} {{other_source_in_scop

e}}

2.2.1. Current Customer Infra details

Was ZPA Connector deployed in POC? {{zpa_connector_deployed_POC}}

Are IT supported VOIP services/servers (SIP, Lync, {{zpa_sip_voip_access}}

Jabber, Skype) publicly accessible from Internet?

Is Distributed File System (DFS) In Use? {{zpa_dfs_in_use}}

2.3 Zscaler Client Connector

2.3.1 Environment Prerequisites

• Whitelist Zscaler Client Connector Processes listed here in host AV and host FW
• ZPA firewall requirements can be found here

2.3.2 Forwarding Profile(s)

The forwarding profile tells the Zscaler Client Connector how to treat traffic from your users' systems in
different network environments for the Zscaler Internet Access (ZIA) and Zscaler Private Access (ZPA)
services. You can configure as many forwarding profiles as you need, then select the appropriate one when
configuring your App Profiles.

Profile Definition

Profile Name {$FORWARDING_PROFILE_NAME}

Trusted Network Criteria

Subhead
date
 Conditional Match Any

DNS Search Domains example.com

Host Name host.example.com

Resolved IPs for Host {$RESOLVED_IP_HOST}

Name

Windows Driver Selection

Tunnel Driver Type Packet Filter Based

Forwarding Profile Action For ZPA

On Trusted Network None

VPN Trusted Network Same as "On Trusted Network"

Off Trusted Network Tunnel

2.3.2.1.1 App Profile(s)

OS and Setting Value Description

Windows

Name {$ZCC_PROFILE_NAME}

Rule Order 1

Policy Status Enabled

Groups {$SELECT_GROUP} Specify user groups

Logout Password {$SET_LOGOUT_PASSWORD} ZCC logout password

Disable Password {$SET_DISABLE_PASSWORD} ZCC Disable

password

Forwarding Profile {$SELECT_FORWARDING_PROFILE} Specify forwarding

profile

Subhead
date
Log Mode Debug Logging mode level

Log File Size in MB 100 Maximum log file size

Mac OS X

Name {$ZCC-PROFILE-NAME} Alpha numeric policy

name

Rule Order 1

Policy Status Enabled

Groups {$SELECT_GROUP}

Logout Password {$SET_LOGOUT_PASSWORD} ZCC logout password

Disable Password {$SET_DISABLE_PASSWORD} ZCC Disable

password

Forwarding Profile {$SELECT_FORWARDING_PROFILE} Specify which profile

to use

Log Mode Debug Logging mode level

Log File Size in MB 100 Maximum log file size

Android

Name {$ZCC_PROFILE_NAME} Alpha numeric policy

name

Rule Order 1

Policy Status Enabled

Groups {$SELECT_GROUP}

Logout Password {$SET_LOGOUT_PASSWORD} ZCC logout password

Uninstall Password {$SET_UNINSTALL_PASSWORD} ZCC Uninstall

password

Disable Password {$SET_DISABLE_PASSWORD} ZCC Disable

password

Subhead
date
 Forwarding Profile {$SELECT_FORWARDING_PROFILE} Specify which profile
to use

Log Mode Debug Logging mode level

Log File Size in MB 100 Maximum log file size

iOS

Name {$ZCC_PROFILE_NAME} Alpha numeric policy

name

Rule Order 1

Policy Status Enabled

Groups {$SELECT_GROUP}

Profile Passcode {$SET_PROFILE_PASSCODE} ZCC Uninstall

password

Logout Password {$SET_LOGOUT_PASSWORD} ZCC logout password

Disable Password {$SET_DISABLE_PASSWORD} ZCC Disable

password

Forwarding Profile {$SELECT_FORWARDING_PROFILE} Specify which profile

to use

Log Mode Debug Logging mode level

Log File Size in MB 100 Maximum log file size

2.3.3 Packaging and Rollout Guidelines

• Prepare Windows and MAC installation packages with the below switches
• Windows
○ Please refer to the KB for MSI installation instructions. Use below switches
■ CLOUDNAME = <<Zscaler Cloud Name>>
■ USERDOMAIN= <<User Domain Name >>
■ HIDEAPPUIONLAUNCH=1
• Use SCCM/GPO to distribute ZCC installer for Windows

Subhead
date
 • MAC
○ Please refer to KB for customizing the MAC installation options. Please use the below
switches
■ --cloudName <<Zscaler Cloud Name>>
■ --userDomain <<User Domain Name >>
■ --hideAppUIOnLaunch 1
• Use the package management tool to distribute ZCC installer for MAC OS

• For iOS and Android devices, please use the MDM solution in order to install ZCC with the following
switches:
■ cloudName <<Zscaler Cloud name>>
■ userDomain <<User Domain name>>
Deployment examples can be found on the help portal

• Deploy only when the user is in the office or if connected through VPN
• Do not push enrollments for more than 1K users simultaneously. Should you deploy to more than 1K
users in a day, please maintain a gap of 3 to 4 hours between every batch of 1K users.

3 ZPA Certificates
ZPA issues certificates to Connectors and clients (i.e., user devices enrolled with the Zscaler Client
Connector) so that it can authenticate them before each connection. To allow ZPA to issue these
certificates, you must specify which signing certificate ZPA must use to sign certificates issued
to Connectors, and which signing certificate it must use to sign certificates issued to clients. These signing
certificates then enable ZPA to confirm the identities of the Connector and the client whenever they connect
to ZPA.

For signing certificates, you have two options:

• You can choose to use the default signing certificates provided by ZPA within the admin portal

• You can choose to use your organization's custom signing certificate

If you are evaluating ZPA, Zscaler recommends for expediency that you use the default signing certificates
provided in the ZPA admin portal. When you deploy ZPA to your production environment, you can either
continue using the default signing certificates or generate custom signing certificates, as needed.

Custom signing certificates are mandatory if you are planning to use “Double Encryption” (separately
purchased) feature.

{{customer_name}} will be using Default certificates

Subhead
date
The following certificates should be configured under Administration->Enrollment certificates

Name Creation Date Expiry Date Common Name Use for Zscaler Client
Connector Enrollment

Client TBD TBD TBD yes

Connector TBD TBD TBD no

Root TBD TBD TBD no

4 Connectors and Server Groups configuration

4.1 Connectors

Connectors are one of the main parts of the Zscaler Private Access infrastructure. They provide the
secure authenticated interface between a customer’s servers and the ZPA cloud. Connectors can be
deployed in several forms.

The supported platforms for connectors are:

● Amazon Web Services (AWS)

● CentOS 7.2+
● Microsoft Azure
● Microsoft Hyper-V
● Oracle Linux 7.2
● Red Hat Enterprise Linux 7.2+
● VMware vCenter or vSphere Hypervisor (ESXi)

{{customer_name}} is licensed to deploy up to <Number of connectors> connectors.

Connectors will be hosted in the following locations:

Location BW required Infrastructure Network Topology Connectors / Connector Group

For
application

Subhead
date
 Access

{{DC_Location_1}} {{BW_DC_1}} {{Infra_DC_1}} {{loc_1_topology}}

{{DC_1_City}}

{{DC_Location_2}} {{BW_DC_2}} {{Infra_DC_2}} {{loc_2_topology}}

{{DC_2_City}}

{{DC_Location_3}} {{BW_DC_3}} {{Infra_DC_3}} {{loc_3_topology}}

{{DC_3_City}}

{{DC_Location_4}} {{BW_DC_4}} {{Infra_DC_4}} {{loc_4_topology}}

{{DC_4_City}}

{{DC_Location_5}} {{BW_DC_5}} {{Infra_DC_5}} {{loc_5_topology}}

{{DC_5_City}}

4.2 Servers and Server Groups

In addition to the connector’s configuration, administrators need to configure servers and server
groups which will link the application segments to a connector group. Best practice is to create a
server group for each set of connector groups that serve a specific app or set of apps. Wherever
possible, use dynamic server discovery when defining creating ZPA Server Groups. This simplifies the
configuration and allows ZPA to automatically detect the optimum server instance for each user
request. Server groups will be configured in the way described in the table below.

Server Group Connector Group Servers

TBD TBD Dynamic

Subhead
date
TBD TBD Dynamic

4.3 Connector Deployment Options

Connectors can be deployed in a few ways (described in appendix B). {{customer_name}} will use the
following option in all data centers with connectors.

5 ZPA Authentication
{{customer_name}} will be using {{authentication_vendor}} for authentication. Because the ZPA access is
based on the user data, the authentication is required to make the ZPA work. More information about
authentication with ZPA can be found in Appendix A.

Please refer to the following KB article regarding the IdP configuration for Zscaler Private Access
https://help.zscaler.com/zpa/configuring-idp-single-sign

Subhead
date
As it is possible to use multiple IdP with ZPA, the table below describes which IdPs will be used

User domain IdP description

<<User Domain name>> {{authentication_vendor}}

6 ZPA Application Segment Configuration

6.1 Application Segments and Segment Groups

An application segment is a grouping of defined applications, based upon access type or user
privileges. ZPA features such as double encryption, health check and reporting, etc. are configured per
application segment. Please follow the best practices listed below when configuring the segments:

• It is possible to configure applications based on FQDNs, IP addresses or IP subnets.

However, Zscaler recommends using FQDNs to define applications wherever possible
• Do not use port 53 in the application segments in order to avoid connection issues.
• Do not use double encryption for the application which already use encrypted protocol (like
HTTPS)
• It is possible to configure applications with a wildcard domain (i.e. *.domain.com), which will
allow ZPA connectors to discover applications automatically
• It is not possible to use “continuous health reporting” for applications configured with more
than 10 ports or applications configured for application discovery
• If there are some specific applications which should be bypassed from ZPA and might match
an “application discovery” segment, there should be a separate segment configured with
bypass option set to “always”
• If the ZCC trusted network criteria is using DNS to IP resolution, make sure that the FQDN
used there is bypassed from the ZPA
• When configuring application segments, please follow the best practices regarding common
enterprise applications setup
• Please make sure that the Unified Communication Traffic is not forwarded through ZPA
• Each application segment can be placed into a single segment group. This allows
administrators to configure user access policies and timeout policies based on segment
groups.

6.2 Browser Access

Browser Access allows you to leverage a web browser for user authentication and application access
over ZPA, without requiring users to install the Zscaler Client Connector on their devices.

Subhead
date
Name Domain Application Application Port Certificate name
Protocol

TBD TBD TBD TBD TBD

7 ZPA Policies Configuration

7.1 Access Policy

Because ZPA by default blocks access to the applications, there is a need to configure policies which
will allow users to access specific application segments or application segment groups.

• ZPA uses a first match principle when evaluating policies. When a user requests a specific
application, ZPA evaluates your configured policies from top to the bottom. As soon as it finds
a policy that applies to the user, it enforces that policy and disregards all other policies that
follow, including any potentially conflicting policies
• Policies use the following logic:
(Application Segments OR Segment Group) AND SAML Attributes AND Client Types AND
Posture profiles
• If the traffic does not match any of the configured policies, it will be automatically blocked
• Access policy configuration examples can be found here

Policies in {{customer_name}} Corporation will be configured as follows:

Rule Application Segment SAML Client types Posture Action

orde Segments Groups attributes profiles
r

1 TBD TBD TBD TBD TBD allow

2 TBD TBD TBD TBD TBD

3 TBD TBD TBD TBD TBD

Subhead
date
7.2 Timeout Policy

Timeout policies allow administrators to define re-authentication time interval and a user application
session idle timeout for each application segment group. More information about timeout policies can be
found in the KB article

Re-authentication interval allows Zscaler cloud to update user information, because all information is
sent to Zscaler as SAML attributes during the user authentication. By default, the re-authentication
interval is configured to 7 days, Zscaler recommends any value between 24 hours and 7 days
(depending on how often the changes in the user directory are made).

{{customer_name}} will use the following timeout policies:

Rule Order Authentication Idle Segment SAML Client Types

Connection Groups attributes
Timeout timeout

TBD TBD TBD TBD TBD TBD

Default rule 7 days Default Any Any Any

7.3 Posture Profiles Configuration

The device posture profile is a set of criteria that a user’s device must meet in order to access
applications with ZPA. To learn more about device posture profiles, see About Device Posture.

Profile Name Platform Posture Type Details

TBD TBD TBD TBD

TBD TBD TBD TBD

TBD TBD TBD TBD

Subhead
date
8 Log Streaming Service
The Log Streaming Service (LSS) provides a better understanding of the information coming from the ZPA
service, by allowing an administrator to create log receivers that can receive information about Connectors
and users. LSS is deployed using two components, a log receiver and a ZPA Connector. LSS resides in
ZPA and initiates a log stream through a ZPA ZEN. The Connector resides in the company's enterprise
environment. It receives the log stream and then forwards it to a log receiver.

The LSS can be deployed on a regular Connector Group that also supports application access, however for
production deployments Zscaler strongly recommends that Connectors will be installed adjacent to the
SIEM and added to a group dedicated to receiving the logs. Otherwise a burst of user traffic that consumes
the available bandwidth through a Connector, could disrupt log streaming (which is best effort application)
resulting in some loss of logs.

Log receivers at {{customer_name}} to be configured in the way shown below

Name FQDN or Connector Log SAML App Segment Client Session

IP Group Type Attributes Segments Types Status
address Groups Codes
and port

TBD TBD TBD TBD TBD TBD TBD TBD TBD

TBD TBD TBD TBD TBD TBD TBD TBD TBD

9 Appendix A – Authentication with ZPA

To access applications via ZPA, users must authenticate into Zscaler Client Connector (ZCC) using any
SAML 2.0 compliant identity provider (IdP) using the service provider-initiated (SP-initiated) model. IDP

Subhead
date
should be able to authenticate all users including external (Should be accessible from the internet).

10 Appendix B – Connector Overview and Deployment

Requirements
10.1 Overview

Connectors provide the secure authenticated interface between a customer’s servers and the ZPA cloud. Connectors
can be deployed in several forms. Zscaler distributes a standard virtual machine (VM) image for deployment in
enterprise data centers, local private cloud environments such as VMware, or public cloud environments such as
Amazon Web Services (AWS) EC2. Additionally, Zscaler provides packages that can be installed on supported Linux
distributions. Connectors can be deployed in a few options:

Subhead
date
10.2 Deployment Requirements

1. Open Firewalls for Connector outbound communication, the firewall requirements can be
found here to deploy connectors.
2. Install the Connectors on an internal network segment, adjacent to the applications that they
are to provide connectivity to;
3. Ideally that network segment should be configured with a default route to the Internet;
4. The Connector should be configured to contact an internal DNS server capable of resolving
hosts for all the applications that need to be supported, and for hosts on the Internet;
5. The Connectors should have unrestricted access to the applications, with no protocol or port
limitations or restrictions, to include ICMP access;
6. While an explicit proxy on the Connector enrollment and subsequent data path can be
supported, it is certainly not recommended. Also remember that any attempt at SSL
interception on the Connector’s traffic will cause ZPA communications to fail (because of the
certificate pinning).

Note that ICMP access to UDP applications is a hard requirement, as it is used to determine the RTT to
the application host (which is important for making load-balancing decisions). For TCP applications ICMP
access is less critical although highly desirable.

Subhead
date
For ‘location-sensitive’ apps, such as Active Directory domain controllers used for DFS and other AD
services, where the user needs to be associated to a local AD Domain Controller, the following best
practices apply:

1. You SHOULD statically define the site location (Latitude and Longitude) in the connector group
definition, as this is used to determine the geographically closest instance of an application.
2. You MUST use location-based connector groups (meaning that all connectors at site A are in
connector group A, all connectors at site B are in connector group B, etc.); this is to ensure that the
user is always connected to an application instance that is local to them.

For apps that are not location-sensitive, and all UDP-based apps are ICMP-reachable, then the
following best practices apply:

1. You MAY use a single connector group per Geo (for example, all US connectors are in a US
connector group, all EMEA connectors are in an EMEA connector group) to allow the system to
choose an optimal path based on the RTT between the Connectors and application instances. In
this case, the Connectors in one Geo SHOULD NOT be able to reach applications in another Geo
(to avoid any possibility of sub-optimal path selection). Note that if you only have end users within a
single Geo, then you should have all your Connectors in the one Connector Group.
2. Connector Groups that have Connectors at many different geographic locations SHOULD NOT
have the location (Latitude and Longitude) defined in the Connector Group definition. Note that
while having this defined would not impact optimum path selection, it would be inaccurate and
potentially confusing for future administrators.

11 Appendix C – FAQ and Basic Troubleshooting

11.1 FAQ

• Do I have to worry about backing up connectors?

• No, there’s nothing stored on it except the certificates.
• What if I lose access to the connector and forget the password?
• Just make a new one and delete the old one.
• How are connectors monitored?
• We currently provide monitoring through the health area of the Admin UI, and this will expand over
time. Also understand that a failed connector will have its routes removed by our application health
monitoring and will no longer be used if it goes away.
• How does connector failover work?
• Each connector advertises the applications and servers it can reach to the cloud and connections are
dynamically load balanced across the available routes to an application. If routes go away, new
connections will use new routes.
• In every connector group you should have at least two connectors.
• How do connector upgrades work?

Subhead
date
 • On a per connector group basis, customers may pick a day of the week, and hour of the day
as a maintenance window. Upgrades to connectors will start during that window if they are
available. The system is also careful to ensure that it doesn’t start the next upgrade until the
previous one has finished.

11.2 Basic Troubleshooting

• Network configuration: Firewall Rules

• Every connector MUST be able to reach every broker (ZPA-ZEN) https://ips.zscaler.net/zpa
• Connectors also need to be able to reach the applications that they are providing access to
• Network configuration: Internal network
• Verify Connector VMs are on the correct VLAN
• Verify Connector VMs don't share IP address with other device in the network
• Verify Connector VMs have working DNS servers and are able to resolve int/ext hostnames.
• Verify Connector VMs have a functioning default route
• Connector Enrollment/Authentication :
• Provisioning key: Verify the provisioning key was entered correctly.
• Verify provisioning key still has uses left
• Verify there are no time synchronization issues.
• App/ZPA configuration:
• NO CONNECTOR AVAILABLE: Means that when we attempted to reach that App for a
Z-app client, there were no connectors advertising health for it at all
• Could be caused by very stringent Server Group -> Connector Group assignment
• Recommended to have more than connector group assigned to a server group

Subhead
date
11. Appendix A: Requirements and Discovery -
*(SA & SE - A review by pre-sales is recommended)

1.1.Products Purchased

Product Purchased

Zscaler Internet Access {{product_purchased_zia}}

Zscaler Private Access {{product_purchased_zpa}}
Z Shift {{product_purchased_zshift}}

1.2.Infrastructure
Capture information about customer’s network infra, routers, switches

Network Infrastructure

Internet Breakouts {{internet_egress_points}}

{{current_proxy}}
Current Secure Web Gateway (SWG) Other: {{SWG_other}}
Current Network Firewall {{current_network_firewall}}
{{gre_supported}} - {{gre_supported_device}}
GRE support Other: {{gre_other}}
{{IPsec_supported}} - {{IPsec_supported_device}}
IPSec support Other: {{IPsec_other}}

{{Geo_Locations}}

Geographical locations Other: {{geo_location_other}}

How is traffic forwarded to current SWG {{traffic_fwd_method_current_current_swg}}
Is Default route available in the network {{default_route_available}}

Subhead
date
 Remote Access VPN

VPN vendor {{VPN_VENDOR}}

VPN connection {{VPN_TYPE}}
VPN mode {{VPN_MODE}}

Can internal DNS Servers resolve external

domains {{DNS_EXTERNAL_RESOLVABLE}}
Other {{Vpn_Other}}

Security Infrastructure

CASB {{CASB_VENDOR}}
{{SIEM_VENDOR}}
SIEM vendor Other: {{SIEM_Other}}
DLP {{DLP_VENDOR}}
{{SANDBOX_POLICY}}
Sandbox {{SANDBOX_VENDOR}}
Is SSL inspection Used {{SSL_SCANNING_USED}}
Any apps using Application Layer Gateway (ALG)
feature on Firewall {{ALG_FEATURE_USER}}
Is FW default blocking all outbound connections {{FW_DEFAULT_BLOCK}}

1.3.Traffic Sources and Network segmentation

The following network types are used within your environment.

Traffic source Network Segmentation In Scope

Windows {{WIN_IN_SCOPE}}
{{WINDOWS_NETWORK_SEGMENTED}}
Laptops/Desktops

Subhead
date
 MAC {{MAC_NETWORK_SEGMENTED}} {{MAC_IN_SCOPE}}

VDI (Virtual {{VDI_IN_SCOPE}}

{{VDI_NETWORK_SEGMENTED}}
Desktop)

Shared {{SHARED_PC_IN_SCOPE}}
{{SHARED_PC_KIOSK_SEGMENTED}}
Machines/Kiosk

Corporate Android {{Android_IN_SCOPE}}

{{ANDROID_NETWORK_SEGMENTED}}
Devices

Corporate IOS {{IOS_IN_SCOPE}}

{{ANDROID_NETWORK_SEGMENTED}}
Devices

Servers {{SERVERS_NETWORK_SEGMENTED}} {{SERVERS_IN_SCOPE}}

Printer/IOT/Netwo {{IOT_IN_SCOPE}}
{{IOT_NETWORK_SEGMENTED}}
rk devices

BYOD {{BYOD_NETWORK_SEGMENTED}} {{BYOD_IN_SCOPE}}

Guest {{GUEST_NETWORK_SEGMENTED}} {{GUEST_IN_SCOPE}}

other NA {{other_source_in_scope}}

1.4.User management

User Management

Total Users {{Total_Users}}

Road Warriors {{Total_Remote_Users}}
User Directory {{USER_DIRECTORY_TYPE}}
No of Active Directory Forests {{NUNBER_AD_FOREST}}
SAML 2.0 Federation Vendor {{authentication_vendor}}
Can IdP Authenticate All Users {{IDP_USER_SCOPE}}
Is IdP accessible over the Internet for remote users {{IDP_INTERNET_ACCESS}}
Integrated Windows Authentication (IWA) {{IWA_REQUIREMENT}}
Other {{idp_other}}

Subhead
date
1.5.End user environment

End User Environment

Using WinHTTP {{USING_WINHTTP}}

Using WPAD {{USING_WPAD}}

Operating System Package Management Antivirus

Windows {{WIN_PKG_MANAGEMENT_TOOL}} {{WIN_CLIENT_AV}}

MAC OS X {{MAC_PKG_MANAGEMENT_TOOL}} {{MAC_CLIENT_AV}}

GNU/Linux {{LINUX_PKG_MANAGEMENT_TOOL}} {{LINUX_CLIENT_AV}}

Android {{ANDROID_PKG_MANAGEMENT_TOOL}} {{ANDROID_CLIENT_AV}}

iOS {{IOS_PKG_MANAGEMENT_TOOL}} {{IOS_CLIENT_AV}}

Other {{zia_packet_mgmt_other}} {{zia_AntiVirus_other}}

1.6.Data privacy requirement

User Environment

Do you need to comply with EU data protection regulations? {{LOG_STORE_IN_EU}}

Do you need to store all logs in US {{LOG_STORE_IN_US}}

Subhead
date