Overview of Ivanti Neurons for Zero Trust Access

•Securing a Diverse Application Infrastructure

•Hyper-Converged Zero-Trust Access

•An Overview of Ivanti Neurons for Zero Trust Access

•Deploying and Using nZTA

•Using a Custom Domain

•Deploying Gateways

•Defining User Authentication

•Publishing Applications

•Enrolling a User Device

•Summary of Steps to Configure Your nZTA Deployment

Securing a Diverse Application Infrastructure

To enhance an enterprise’s ability to protect its systems, services, and data, IT teams can adopt a zero-trust network security architecture. The zero-trust model works on the principle that no single client entity is automatically trusted, regardless of whether they are inside or outside the organizational network perimeter. Each client connection must have its identity verified by a trusted service or policy before access is granted.

As organizations move away from traditional application deployment models and begin to adopt hybrid and multi-cloud service-based infrastructures, the notion of zero-trust must be a extended to encompass the means to centrally manage application access and security for all users across the enterprise, regardless of device type and location.

For example, an enterprise with SaaS, 3rd-party cloud, and on-premise applications might need to define end-to-end secure access policies through a combination of:

• User authentication method (Active Directory, LDAP, local authentication)
• Device compliance policy (operating system, antivirus definition, root access)
• Infrastructure type (AWS/Azure, on-premise vSphere, KVM)
• Application type (SaaS applications such as O365/SFDC, Cloud apps, on-premise apps)
• Additional security postures (such as location, time, usage patterns)

In addition, this model gives rise to complex requirements for visibility and compliance reporting. At any time, an organization might need to see the following types of information:

Hyper-Converged Zero-Trust Access

Ivanti Neurons for Zero Trust Access (nZTA) addresses the requirement for an enterprise-level zero-trust secure access management platform. It offers the following features and benefits:

• True zero-trust access as a service for hybrid and multi-cloud
  • Authentication and authorization before any access
• Separation of control and data planes
  • All user data goes through only the relevant nZTA Gateway deployed in the organization’s datacenter or virtual private cloud
• Dark cloud to reduce the attack surface
  • nZTA Gateways are not accessible by the client end-point until authorized to do so by the Controller
  • Client end-points never access the applications directly; only through an encrypted data tunnel via the nZTA Gateway
• Smooth migration

An Overview of Ivanti Neurons for Zero Trust Access

Ivanti Neurons for Zero Trust Access (nZTA) is a cloud-based SaaS (software as a service) application that forms part of the Ivanti Neurons for Secure Access family. It provides fully-managed zero-trust authentication and access control for an organization’s application infrastructure.

nZTA is developed according to the principle of SDP (Software Defined Perimeter). Where traditional network-based security architectures use firewalls at the network perimeter to limit access to resources, SDP is based on a need-to-know policy-driven model. Client devices are verified and authorized before access to applications is granted. Application infrastructure cannot be detected remotely, and has no visible DNS information or exposed IP addresses. This protects networked resources from many common network-based attacks.

nZTA enables system administrators to define end-to-end authorization and authentication policies that control application visibility, access, and security for all users and their devices. Administrators can deploy applications of any type in a variety of hybrid cloud and on-premise datacenter environments, with nZTA providing users seamless secure access to only those applications for which they are authorized to use, regardless of geographic location and client device platform.

nZTA facilitates authorization policy enactment for any combination of users, devices, applications, and infrastructure.

Deploying and Using nZTA

A nZTA deployment consists of a Controller service and one or more application Gateways positioned at each location an organization hosts its resources and applications. This might be in a public or private cloud, within a datacenter, or inside a virtual host environment.

The topology of a nZTA deployment

End users use Ivanti Secure Access Client to authenticate with the Controller, which runs an Authentication, Authorization and Accounting (AAA) Service. The Controller then enables direct and encrypted communication between the user and the nZTA Gateways that protect the user’s authorized resources. This mechanism avoids the general exposure of public IP addresses, and separates the control plane from the data plane.

To learn more about using Ivanti Secure Access Client with nZTA, see Enrolling Mobile/Desktop Clients and Using Ivanti Secure Access Client with nZTA.

After you have defined your secure access policy, or policies, the Controller automatically synchronizes the configuration out to your nZTA Gateways.

System administrators use the Controller to configure, provision, and monitor an enterprise’s application infrastructure. To achieve this, Ivanti provides a Tenant Admin Portal on the Controller. This portal facilitates the following actions:

• Configure a custom domain at which your nZTA service is reached
• Define and deploy nZTA Gateways
• Register authentication services and policies
• Publish resources and applications
• Create authorization rules and policies for users and devices
• Enroll users
• Perform management and real-time analysis of traffic flow and application access across the enterprise
• Manage your Tenant Admin Portal settings

Using a Custom Domain

Your nZTA tenant subscription is deployed, by default, as a unique endpoint at a domain provided by Ivanti. Enrollment and sign-in endpoints are then configured at this FQDN through user authentication policies.

Should you require it, you can provision a custom domain to be used in place of the Ivanti-provided domain.

IMPORTANT: It is essential to determine whether a custom domain is required at the outset of your subscription, and particularly before you have deployed any Gateways or enrolled any users.

Deploying Gateways

nZTA requires you to set up Gateways to manage access to your applications and resources. You deploy one or more Gateway instances at each location your applications are hosted, whether at a physical datacenter, a private or public cloud-based service, or some hybrid combination. Each Gateway communicates with the Controller to ensure that access requests are authorized.

nZTA supports two main Gateway types, depending on your subscription:

• nZTA Gateways
• Ivanti Connect Secure (ICS) Gateways

This guide describes how to install and configure nZTA Gateways. For details pertaining to an ICS Gateway, refer instead to the "ICS Gateway Onboarding Guide" in the nSA documentation portal.

A nZTA Gateway is a virtual machine that operates as a headless instance at the perimeter of the logical network used by your datacenter or cloud. A nZTA Gateway must be contactable by the Controller, other nZTA Gateway instances at the same location, and the applications that reside there. nZTA supports nZTA Gateways running on Microsoft Azure, Amazon Web Services (AWS), and VMware vSphere. Ivanti provides template images for each environment.

To obtain the latest nZTA Gateway virtual machine template images, see the Release Notes.

Deploying nZTA Gateways to your cloud and datacenter locations

The process of registering a nZTA Gateway identity with the Controller produces a package of settings known as a Gateway definition that you apply to the Gateway virtual machine during deployment. These settings enable the nZTA Gateway to establish secure communication with the Controller.

Make sure the nZTA Gateway instance does not exist prior to registration with the Controller. The Gateway definition file is designed to be applied to a new virtual machine instance at deployment time only.

To register a new nZTA Gateway with the Controller, use the Tenant Admin Portal. The Controller provides a step-by-step workflow to define your nZTA Gateways, requiring basic identification and networking details. After you complete this process, you can download the definition file ready for insertion into your nZTA Gateway virtual machine at deploy time.

A Gateway definition file is valid for 24 hours. If this period expires, you must replace the nZTA Gateway to generate a new definition file.

Then, when you create the nZTA Gateway virtual machine instance in your cloud or on-premise management console, you apply the definition file when requested by the template. A newly launched nZTA Gateway instance registers itself with the Controller, and any subsequent policy changes made on the Controller are automatically synchronized out to all nZTA Gateways.

Using Gateway Groups for High Availability

nZTA provides the ability to enhance your application delivery by allowing the deployment of a group of two or more nZTA Gateway instances in front of the same applications. Depending on the approach taken, this can provide improvements for:

• Availability: If one Gateway becomes overloaded or unresponsive, traffic is routed to another Gateway in the group.
• Throughput: Balancing the load between all Gateways in the group to take full advantage of their capacity.
• Load partitioning: A non-balancing approach to distributing traffic between Gateways in the group.
• Latency reduction: Routing an end user's traffic to the Gateway nearest to them.

A nZTA deployment provides two methods to control how traffic is routed:

1. The Controller chooses which Gateway to use, see Using Controller for Gateway Selection.
2. You deploy a load-balancer to route traffic to the Gateways, see Using an Administrator-Deployed Load-Balancer.

The Controller uses the concept of Gateway Groups to manage each of these deployment models. A Gateway Group contains Gateways that are considered part of a single high-availability group, see Using Gateway Groups in your Secure Access Policies.

Using Controller for Gateway Selection

To allow the Controller to select a Gateway, make sure your Gateway Group has no load-balancer defined as part of its configuration.

In this scenario, no additional infrastructure is required.

When Gateways in the group are deployed across different locations, the Controller selects the Gateway that is geographically closest to the end-user, based on the end-user's IP address. When Gateways in the group are configured with the same location, the end-user is directed to the Gateway that is alphabetically first by name. If a gateway fails, the end-user is automatically directed to use the next available Gateway in the group by the same criteria.

This mode provides improved availability over a standalone Gateway. In addition, when Gateways are deployed across multiple locations, it can partition load and reduce latency for end-users.

Using an Administrator-Deployed Load-Balancer

An administrator can deploy a load-balancer to distribute traffic between the Gateways in the group through the following scenarios:

• As an in-path load-balancer to provide more rapid failure detection, and to load-balance traffic across Gateways when they are deployed in the same location to maximize throughput. An in-path load-balancer does not provide for latency reduction as all the Gateways in the group are deployed in the same location.

  For on-premise Gateway deployments, Ivanti recommends Pulse Secure Virtual Traffic Manager (vTM). For cloud-based Gateway deployments, you can again use vTM or the built-in load balancing capabilities of AWS or Azure. To learn more about vTM, contact Ivanti Technical Support or visit www.ivanti.com. For more details on available load balancers in AWS or Azure, see the relevant product documentation.

  When using vTM for load-balancing, Ivanti recommends you configure the following settings in the vTM Admin UI to ensure proper fail-over functionality:

  1. Click Services > Virtual servers and edit your designated HTTPS virtual server. In the virtual server configuration, click Protocol Settings > TCP Connection Settings and enable close_with_rst. This setting closes connections from clients with a RST packet rather than a FIN packet and avoids the TIME_WAIT state.
  2. Click Services > Pools and edit your designated HTTPS pool. In the pool configuration, enable the following settings:
     • Click Protocol Settings > TCP Pool Settings and enable node_connclose. This setting closes all connections to a node if vTM detects that the node has failed.
     • Click Protocol Settings > TCP Protocol Options and enable node_close_with_rst. This setting closes connections from clients with a RST packet rather than a FIN packet and avoids the TIME_WAIT state.

  You deploy an in-path load-balancer in front of your Gateway instances and raise a public IP address on its front-end interface. You then configure the load balancer with a pool of nodes representing the external IP addresses of your Gateway instances. End users connect to the load-balancer, which in turn forwards on the connection to one of the available Gateways based on the load balancing algorithm you choose (such as round-robin). The load balancer can be configured with a health monitor to perform connectivity checks with your Gateways.

  To use an in-path load-balancer, enter the IP address or FQDN of the load-balancer's public interface in the load-balancer field of the Gateway Group configuration (see Working with Gateways).

  nZTA supports Gateway health monitoring using TCP port 443.

  

This diagram demonstrates high availability based on a pair of Gateways. You can add further Gateway instances according to the expected load on the applications at that location.

• As a global load-balancer to distribute traffic between Gateway instances based on client proximity to the Gateway.

Using Gateway Groups in your Secure Access Policies

To implement high availability, you configure a Secure Access Policy to use a Gateway Group rather than an individual Gateway. For all policy updates, the Controller automatically synchronizes changes with all Gateways in the group.

Note the following when using Gateway Groups:

• A Gateway is available to be assigned to a Secure Access Policy as part of a Group, or as an individual instance, but not both. That is, a Gateway that is added to a Gateway Group is no longer available to be assigned to a Secure Access Policy by itself.
• A Gateway must be registered and connected before it is available to be added to a Gateway Group.
• Where the Controller is used for Gateway selection, all Gateways in an affected group must have a public IP address configured.
• Gateway instances use different certificates for mTLS communication when part of a Gateway Group. When you add a Gateway to a Gateway Group, this triggers a task to renew the Gateway certificate to match that used by the Group. Conversely, if you remove a Gateway from a Gateway Group, this again triggers a task to renew the Gateway certificate to ensure validity as an individual instance.
• A removed Gateway does not retain any user or device policies previous synchronized to it by the Controller.

Using Network Load Balancer for High Availability in AWS

If you plan to use Network Load Balancer (NLB) to implement high availability for a group of Gateways deployed in AWS, Ivanti recommends you configure a Target Group with a Target Type of "IP":

Defining User Authentication

nZTA provides user authentication through authentication policies. Policies cover the primary scenarios of user enrollment, user sign-in, and administrator sign-in, and the Controller includes built-in policy definitions for all three. nZTA additionally allows you to define your own custom enrollment and sign-in policies to facilitate specific authentication paths for different groups of users or parts of your organization.

An authentication policy defines the application of an authentication method for a specified access URL. You create methods based on your user authentication requirements and assign them to the appropriate policies. As a user connects to the access URL defined in a policy, the associated method is employed to authenticate the user device.

nZTA facilitates Multi-Factor Authentication (MFA) through the configuration of an optional secondary authentication method in a policy. When MFA is deployed, a connecting user would need to satisfy the requirements of both primary and secondary authentication methods before access is granted. nZTA allows the use of Local authentication and Time-based One Time Password (TOTP) as secondary methods.

nZTA also provides for the definition of user rules and user groups. User rules act as filters and define the basic criteria by which users’ credentials must match in order for authentication to proceed. User groups encapsulate an authentication policy with one or more user rules to provide a complete user authentication definition for your Secure Access Policy.

The relationship between user groups, rules, authentication policies and methods

Ivanti recommends you define your authentication methods and user rules first. Then, create or update authentication policies for user enrollment and sign-in based on the authentication methods that you want to apply in that scenario. Finally, create a user group based on your policy and add any applicable user rules.

Creating User Authentication Methods

nZTA supports user authentication through the following methods:

Local Authentication

nZTA can operate a local authentication policy based on a defined list of users held internally in the Controller. User authentication requests are compared against this list to determine access rights. You create and manage this list manually through the Tenant Admin Portal.

nZTA supports the use of Local Authentication as a primary or secondary authentication mechanism.

SAML Authentication

SAML (Security Assertion Markup Language) is an open-standard XML-based message framework, used to exchange information concerning the authentication and authorization of user agents attempting to access an organization’s web services. SAML is often used for web browser single sign-on (SSO) services.

SAML deployments typically involve two participant types:

• Service Provider (SP): provides the resources to be protected
• Identity Provider (IdP): performs the authentication and authorization checks required by your resources

nZTA can function as a SAML SP to control user access to your application infrastructure, using an externally-defined service (for example, Azure AD) as the IdP. Access is permitted only when a valid SAML token is presented by the requesting user agent, who has in turn obtained the token from the IdP.

nZTA supports the use of SAML in Multi-Factor Authentication as a primary authentication mechanism only.

To configure nZTA to use a SAML authenticator, you must establish a trusted SAML connection between nZTA and a suitable identity provider. To create the connection, nZTA and the identity provider must both be configured with authentication data identifying each other.

In other words, when you configure an identity provider application to operate as a SAML IdP, you obtain an IdP metadata package file containing configuration details suitable for uploading to nZTA (as the SP). After you upload the IdP metadata to nZTA, nZTA in return generates its own SP configuration metadata package file for uploading back to the IdP.

Configuring nZTA with a SAML authentication method

This process of authentication metadata-sharing establishes the IdP as a trusted authenticator within nZTA. The IdP, in turn, acknowledges nZTA as a trusted SP.

This guide provides information on configuring trusted connections to supported SAML authenticators. For more detailed instructions, or for deployment scenarios not covered by this guide, refer to the documentation provided by your IdP vendor.

nZTA uses independent authentication policies to handle user enrollment and user sign-in processes. When configuring SAML authentication, you typically create two separate SAML applications in the IdP to handle each process individually. This means that for each authentication policy you must configure a separate nZTA authentication method and, for each method, perform the IdP/SP metadata handshake to establish a trusted connection with the associated SAML application. Ivanti recommends you configure your IdP SAML applications and obtain the corresponding metadata files before you configure your nZTA authentication methods.

TOTP Authentication

Time-based One Time Password (TOTP) is defined in RFC6238 as an authentication mechanism where a one-time password (also known as a token) is generated by an authentication server and client from a shared secret key and the current time. This is implemented in nZTA with the Controller acting as the TOTP authentication server.

Any third-party TOTP applications (for example, Google Authenticator, Microsoft Authenticator, and so on) available on the mobile and desktop client platforms generate TOTP tokens.

nZTA supports the use of TOTP in Multi-Factor Authentication as a secondary authentication mechanism only.

Using User Authentication Policies

Users trigger authentication by connecting to the access URL defined in your authentication policies. These policies reference authentication methods, as described in Creating User Authentication Methods, and cover the primary scenarios for authenticating user connections:

• User enrollment
• User sign-in
• Administrator sign-in

nZTA supports Multi-Factor Authentication for User sign-in and Administrator sign-in type policies only.

nZTA is pre-configured with built-in "default" policies for each of these scenarios.

Viewing the default user authentication policies provided by the Controller

The access URL defined in each policy is appended to the tenant FQDN and serves as a complete endpoint for that activity. For example, if your tenant FQDN is "example.company.com", the default sign-in endpoint for your end-users is https://example.company.com/login/ and the default enrollment endpoint is https://example.company.com/login/enroll/.

The specific access URL to which you connect for enrollment depends on the Ivanti Secure Access Client version installed on the device:

• For Ivanti Secure Access Client versions defined as recommended for nZTA 21.9.2 or later, or for browser-based enrollment, you enroll a device by connecting directly to the access URL in a user sign-in policy. You do not connect to the enrollment policy directly (enrollment policies are linked to sign-in policies to handle the case where a connecting device is not yet enrolled).
• For Ivanti Secure Access Client versions earlier than those recommended for nZTA 21.9.2, you enroll a device by connecting to the access URL in an enrollment policy. Thereafter, enrolled devices connect to the access URL in your default user sign-in policy.

For details of recommended and supported Ivanti Secure Access Client versions, see the Release Notes.

The built-in default policies cannot be replaced or deleted, yet can be edited to update the authentication methods used in each case. For standard deployments involving a single authentication workflow for all enterprise users, these policies should be sufficient.

Adding Custom Authentication Policies

In addition to the built-in authentication policies, you can add custom policies to enable further group-specific login scenarios. You can add, edit, and delete custom authentication policies as required.

In other words, where you only require a single policy for all enterprise users containing an authentication method suitable for everyone, the built-in default policies are likely suitable for your needs. However, you might want to authenticate certain groups of users against a different authentication method. In this scenario, you can set up custom policies, each containing a separate authentication method suitable for your specific group of users (for example, one policy/method for Sales staff versus another for non-Sales staff).

In a custom authentication policy, you define a unique Access URL for the activity (for example, "*/login/saleslogin/" or "*/login/salesenroll/"), and the primary authentication method you want to apply in that case. For Multi-Factor Authentication scenarios, you should also define an appropriate secondary authentication method (based on local or TOTP authentication).

Each time you create a custom authentication policy, you configure the user type (or activity) to which this policy should apply:

Multi-Factor Authentication is supported for user sign-in and admin sign-in custom policies only.

Authentication policies defined as a users sign-in type contain a link to an enrollment users policy that you specify. Through this mechanism, un-enrolled user devices connecting to a sign-in endpoint are instead automatically redirected to the relevant enrollment endpoint. For this reason, make sure you create your enrollment policy BEFORE you create a sign-in policy.

As an example scenario:

1. For enrollment, you create a new custom user policy specifying a User Type of "Enrollment Users" and a unique enrollment Login URL such as /login/testenroll. Then, select your required authentication server.
2. To enable your users to sign in post-enrollment, create a separate custom user policy specifying a User Type of "Users". Enter a separate unique Login URL representing the sign-in endpoint, such as /login/testuser. Then, select your required primary (and optional secondary) authentication server. Finally, link in the enrollment policy you created in the previous step.
3. When you add a new nSA connection in Ivanti Secure Access Client, you specify the sign-in endpoint (https://<mydomain>.com/login/testuser). This automatically redirects to https://<mydomain>.com/login/testenroll to complete the enrollment process. An enrollment endpoint must not itself be used for device onboarding from Ivanti Secure Access Client or through a web browser-based enrollment.

Your custom user sign-in policies can be configured to redirect enrollment to either another custom (enrollment) policy, or to the built-in Enrollment Signin policy. The built-in User Signin policy is pre-configured with the built-in Enrollment Signin policy and cannot be modified.

If you use custom authentication policies, you must make sure these policies are mapped to a valid Secure Access Policy. Otherwise, connection attempts to enroll an end-user device to these policy end-points will fail.

For more details on enrolling client devices, see Enrolling a User Device.

Defining User Authentication Rules and Groups

After you have defined a user authentication service, you can proceed to create User Rules and User Groups.

A User Rule is a set of instructions describing whether nZTA should include or exclude a user based on whether the criteria defined in the rule matches the user. For each rule, you specify an attribute of a user’s credentials (such as "username") and a value to match against or to avoid. The value can be a wild-card character, a literal string, or a mixture of both. For example, you might specify a rule of "username MATCHING *@example.com" to apply to all users with user names in the example.com domain.

The attribute to match varies depending on whether your rule is to be used against an internally held user list or a SAML-based external authentication service.

Consider specifying separate user rules for each type of user in your organization. Consider also defining rules for each type of application or resource you want to publish. For example, you might require a rule to filter out those users that are not authorized to access a sensitive data application, such as an HR or payroll system, held in a specific datacenter.

A User Group contains one or more user rules that, when combined with a user authentication service (see Defining User Authentication), create a complete user authentication policy.

This capability, combined with device policies, can actively fulfill the Users and Devices dimensions of your secure access policy. For more information, see An Overview of Ivanti Neurons for Zero Trust Access.

For logins attempted against a URL endpoint defined in a particular policy, the credentials of the user are checked against the corresponding authentication services and user rules to ascertain whether the user is authorized to access the services published at a nZTA Gateway.

Publishing Applications

Application publishing is central to the configuration of your nZTA service. A nZTA application can refer to on-premise applications, web pages, or network locations served from your datacenter and cloud infrastructure. nZTA can also publish resources based on SaaS applications such as Microsoft O365 and Salesforce.

The process of publishing an application encompasses all four dimensions of secure access: users, devices, applications, and infrastructure. For each application, you define its type and then apply to it user rules, device policies, and nZTA Gateway infrastructure governing access to it. For more information on the secure access model, see An Overview of Ivanti Neurons for Zero Trust Access.

Creating a secure access policy

The Tenant Admin Portal allows you to define a complete secure access policy for an application or resource, encompassing the required supporting user rules, device policies, and nZTA Gateway infrastructure.

Defining Applications and Application Groups

When you create a new secure access policy, you select whether to create a policy for a single application or for a group of related applications. Therefore, the Tenant Admin Portal enables you to define applications individually, and where required to then add one or more application definitions to an application group.

An application, or application group, can be associated with only one secure access policy.

When you create a new application definition in the Tenant Admin Portal, make sure you know the following details:

• The Application Details: That is, the URI (Uniform Resource Identifier) you use to access the application, based on a Fully Qualified Domain Name (FQDN). nZTA supports valid entries that match the following forms:

Application Details

URI Scheme	Example(s)
http://<FQDN or IP>[:<port>][/path]	http://www.example.com, http://www.example.com:80, http://www.example.com/myapp, http://www.example.com:80/myapp, http://192.0.2.0, http://192.0.2.0:80, http://192.0.2.0/myapp, http://192.0.2.0:80/myapp
https://<FQDN or IP>[:<port>][/path]	https://www.example.com, https://www.example.com:443, https://www.example.com/myapp, https://www.example.com:443/myapp, https://192.0.2.0, https://192.0.2.0:443, https://192.0.2.0/myapp, https://192.0.2.0:443/myapp
tcp://<FQDN or IP>[:<port>], tcp://<FQDN or IP>[:<port1,port2>], tcp://<FQDN or IP>[:<portA-portB>], tcp://<FQDN or IP>[:*]	tcp://example.com, tcp://example.com:21, tcp://192.0.2.0, tcp://192.0.2.0:1-65535, tcp://192.0.2.0:80,443, tcp://192.0.2.0:*
udp://<FQDN or IP>[:<port>], udp://<FQDN or IP>[:<port1,port2>], udp://<FQDN or IP>[:<portA-portB>], udp://<FQDN or IP>[:*]	udp://example.com, udp://example.com:69, udp://192.0.2.0, udp://192.0.2.0:1-65535, udp://192.0.2.0:161,162, udp://192.0.2.0:*
ssh://<FQDN or IP>[:<port>]	ssh://example.com, ssh://example.com:22, ssh://192.0.2.0, ssh://192.0.2.0:22
rdp://<FQDN or IP>[:<port>]	rdp://example.com, rdp://example.com:3389, rdp://192.0.2.0, rdp://192.0.2.0:3389
ica://<FQDN or IP>	ica://example.com, ica://192.0.2.0
<FQDN>:<port>	www.example.com:9090
<FQDN>:<port1>,<port2>[,...]	www.example.com:9090,9091,9092
<FQDN>:<portA>-<portB>	www.example.com:9090-9099
<FQDN>:*	www.example.com:*
<IP address block with subnet>	192.0.2.0/8, 192.0.2.0/255.0.0.0
<IP address>[/<subnet>]	192.0.2.1, 192.0.2.1/32, 192.0.2.1/255.255.255.255

IPv6 addresses are not supported when defining application details

• The access type. This is one of the following types:
  • Application-level: Defines an on-premise or cloud application.
  • SAML: Defines a trusted connection between nZTA and the application, suitable for SaaS applications.

When using SAML authentication with an application group, make sure you add to a single application group only those applications that use the same SAML authentication source.

For simple application access, you specify the full FQDN, URI or IP address at which the application is accessed. In some cases, you might have multiple applications available at a single primary domain, the full set of which might be unknown to the administrator configuring your nZTA service, particularly with SaaS applications. Instead of locating and defining each of these applications individually, you can create a single application definition based on a wildcard-prefixed FQDN (for example, "*.example.com") and instruct nZTA to employ application discovery on that domain. The method means that a single secure access policy can handle access to all applications discovered at the domain.

nZTA records analytics and metrics for all discovered applications. To learn more about how to track usage, see Reviewing Application Usage.

To learn more about the process of creating applications and application groups, see Adding Applications to the Controller.

Defining an On-Premise Application

Before configuring nZTA to publish your resource, make sure the resource is accessible from the nZTA Gateway you want to use for controlling access. You should obtain the FQDN of the endpoint at which the resource is visible.

nZTA additionally requires a name, description, and icon to represent the resource.

Defining a SaaS Application

The Controller uses SAML to provide a secure connection to a SaaS resource. In this scenario, nZTA acts as a SAML Identity Provider (IdP), with the resource acting as the SAML Service Provider (SP). To learn more about using SAML, see SAML Authentication.

By selecting SAML as the application access type, the Tenant Admin Portal provides the ability to download the IdP metadata file for uploading to the application SP configuration. This action, in turn, should elicit a SP metadata file for uploading back to nZTA.

Defining User Rules and User Rule Groups

A secure access policy links to the same user rule groups as described during the process of configuring user authentication. You create access rules for your enterprise user base and add these rules to a corresponding rule group. You then select a user rule group during the creation of your secure access policy.

For more information, see Defining User Authentication Rules and Groups.

Creating Device Policies and Device Policy Rules

Device policies define the minimum standard a device must meet to be considered compliant with nZTA.

Examples of compliance include:

• All client devices, desktop or mobile, must have anti-virus software installed and enabled.
• A specific application might function securely only on devices using a minimum viable Operating System version.
• Application access on client devices should be restricted to a defined browser type and minimum version.
• Application access should be restricted to a pre-determined range of authorized client device IP addresses.

You create individual device policy through the Tenant Admin Portal and then create / associate device rules to them. As you move on to define your secure access policy, you select a device policy that should be enforced for the selected application, users, and nZTA Gateway.

nZTA includes the following built-in device policies:

• For McAfee AntiVirus (Windows/Mac):

  • McAfeeAVHigh: This is a high strictness policy designed to ensure devices have anti-virus software installed and active, with a virus signature database not more than 2 days old, and a full system scan having been performed. This policy is attached to the built-in McAfeeAntiVirusHigh device rule.
  • McAfeeAVMedium: This is a moderate strictness policy designed to ensure devices have anti-virus software installed and active, with a virus signature database not more than 10 days old. This policy is attached to the built-in McAfeeAntiVirusMedium device rule.
  • McAfeeAVLow: This is a low strictness policy designed to ensure devices have anti-virus software installed and active. This policy is attached to the built-in McAfeeAntiVirusLow device rule.

• For Symantec AntiVirus (Windows/Mac):

  • SymantecAVHigh: This is a high strictness policy designed to ensure devices have anti-virus software installed and active, with a virus signature database not more than 2 days old, and a full system scan having been performed. This policy is attached to the built-in SymantecAntiVirusHigh device rule.
  • SymantecAVMedium: This is a moderate strictness policy designed to ensure devices have anti-virus software installed and active, with a virus signature database not more than 10 days old. This policy is attached to the built-in SymantecAntiVirusMedium device rule.
  • SymantecAVLow: This is a low strictness policy designed to ensure devices have anti-virus software installed and active. This policy is attached to the built-in SymantecAntiVirusLow device rule.

• For TrendMicro AntiVirus (Windows/Mac):

  • TrendMicroAVHigh: This is a high strictness policy rule designed to ensure devices have anti-virus software installed and active, with a virus signature database not more than 2 days old, and a full system scan having been performed. This policy is attached to the built-in TrendMicroAntiVirusHigh device rule.
  • TrendMicroAVMedium: This is a moderate strictness policy rule designed to ensure devices have anti-virus software installed and active, with a virus signature database not more than 10 days old. This policy is attached to the built-in TrendMicroAntiVirusMedium device rule.
  • TrendMicroAVLow: This is a low strictness policy rule designed to ensure devices have anti-virus software installed and active. This policy is attached to the built-in TrendMicroAntiVirusLow device rule.

• For device modification testing:

  • AndroidRootRulePolicy: This policy is designed to ensure that an Android device has not been rooted. This policy is attached to the built-in AndroidRootRule device rule.
  • IOSJailBreakRulePolicy: This policy is designed to ensure that an iOS device is not subject to a jailbreak. This policy is attached to the built-in IOSJailBreakRule device rule.

• For risk-based vulnerability:

  • RiskSenseCriticalNotify: This policy adds robust risk-based vulnerability prioritization and remediation capabilities to Ivanti Neurons for Patch Intelligence. This policy is attached to the built-in RiskSenseCriticalNotifyRule device rule.

You can create additional device policies to match the applications used by your organization. You then associate device policies with your secure access policies as required.

Policies can be based on the following types:

Policy Type	Description
Antispyware	Checks compliance to designated anti-spyware requirements.
Antivirus	Checks compliance to designated anti-virus requirements.
CVE check	Checks for protection against a list of publicly disclosed Common Vulnerability and Exposure (CVE) notices (Windows client devices only).
Command	Runs a command on the client device to check against an expected value (macOS client devices only).
File	Checks for the existence of a known file on the client.
Firewall	Checks compliance to designated firewall requirements.
Location	Checks the client device's geographic location matches, or avoids, a list of defined locations.
Hard Disk Encryption	If encryption software is installed on the client device, this rule type checks the device's hard disks for applied encryption.
Mac Address	Checks the client device's MAC address.
Netbios	Checks the client device's Netbios domain name.
Network	Checks the client device complies with a defined IP address and netmask range.
OS	Checks the client device’s Operating System meets a defined minimum standard.
Process	Checks for the existence of a known process on the client.
Port	Checks the client device's network interface ports.
Patch Management	If patch management software is installed on a client device, this rule type checks for the existence of missing software patches.
Registry	Checks for a value in a registry key (Windows client devices only).
Risk Sense	Supports Allow access, Block access and Notify based on the risk level.
Time of day	Checks resource access requests against compliance with a time-based access schedule.
System Integrity	Checks the system integrity of the client device (macOS client devices only).

Enrolling a User Device

To use nZTA-controlled resources, end users must first enroll their devices with the Controller. This process installs or updates the Ivanti Secure Access Client software and establishes a connection to the Controller in order to obtain policies and details for a user's authorized resources. Ivanti Secure Access Client uses this configuration to establish a secure connection to the nZTA Gateways you deploy to control access to your applications. Through this process, the user is provided a seamless connection to the resources they need and is never aware of the location or extent of the organization’s application infrastructure.

For security reasons, only the authorized user account used to enroll a device is subsequently permitted to sign-in to nZTA on that device.

A new user might arrive at this scenario from one of the following routes:

• An existing Pulse Secure or Ivanti user, with a previous Ivanti Secure Access Client connection to Ivanti Connect Secure (ICS) or similar, see Existing ICS Users.
• A first time nZTA user, with no previous Pulse Secure or Ivanti software installed, see First Time Users.
• An existing nZTA user enrolling a new device, or upgrading a previous version of Ivanti Secure Access Client, see Existing nZTA Users.

To learn more about the processes of enrolling supported mobile and desktop clients, and to see how an admin can manage the list of enrolled devices, see Enrolling Mobile/Desktop Clients.

To learn more about using mobile and desktop clients with nZTA, see Using Ivanti Secure Access Client with nZTA and Enrolling Mobile/Desktop Clients.

Existing ICS Users

Your users might have a previous version of Ivanti Secure Access Client installed if, for example, they are existing ICS users.

To enroll existing ICS users into nZTA, a ICS administrator must first push out the nZTA-ready edition of the client software to the user base. An admin uploads the new client software to the ICS server and activates the nZTA-ready version of Ivanti Secure Access Client from the ICS management console in the same way as any other version. This process ensures that when your users next activate a Ivanti Secure Access Client connection to the server, their device is prompted to download and install the new version.

For more details on this process, see the Ivanti Connect Secure documentation at https://help.ivanti.com.

After the new nZTA-ready version of Ivanti Secure Access Client is installed, the user can configure a nZTA connection using the same process used for other, existing, connections. To create a nZTA connection, compatible Ivanti Secure Access Client versions offer a specific connection type: "Zero Trust Access".

First Time Users

When enrolling a new device on which no previous Ivanti Secure Access Client is installed, an authorized user contacts the Controller through the access URL of a user sign-in authentication policy to activate an initial first-time enrollment of their client device. The Controller responds to a valid enrollment request by activating a download of Ivanti Secure Access Client along with a suitable client certificate.

Existing nZTA Users

Existing nZTA users enrolling a new device follow the same procedures described for a first time user, but based on the additional conditions noted here.

The access URL to which you connect for enrollment depends on the Ivanti Secure Access Client version installed on the device:

• For Ivanti Secure Access Client versions defined as recommended for nZTA 21.9.2 or later, or for browser-based enrollment, you enroll a device by connecting directly to the access URL in a user sign-in policy. You do not connect to the enrollment policy directly (enrollment policies are linked to sign-in policies to handle the case where a connecting device is not yet enrolled).
• For Ivanti Secure Access Client versions earlier than those recommended for nZTA 21.9.2, you enroll a device by connecting to the access URL in an enrollment policy. Thereafter, enrolled devices connect to the access URL in your default user sign-in policy.

For details of recommended and supported Ivanti Secure Access Client versions, see the nSA Controller Release Notes.

After you have enrolled the new device, Ivanti Secure Access Client is installed and configured with the policies and settings relevant to the device type. Your application and resource access rights should be duplicated to the new device.

If a user device is currently using a Beta version of the nZTA-ready Ivanti Secure Access Client, Ivanti advises to remove the nZTA connection from Ivanti Secure Access Client and to re-perform the enrollment procedure through a web browser. For more details, see your support representative.

Summary of Steps to Configure Your nZTA Deployment

The remainder of this guide describes each of the processes you need to follow to fully configure your nZTA deployment.

In summary, the main steps are as follows:

1. Log in to the nZTA Tenant Admin portal
2. Create and deploy your nZTA Gateways
3. Define your user authentication methods and policies
4. Define your user rules and user groups
5. Define your device policies and policy groups
6. Define your applications and application groups
7. Create your complete secure access policy.

The remainder of this guide describes each of these steps in detail.

This guide also provides guidance on client device enrollment (see Enrolling Ivanti Secure Access Client), usage (see Using Ivanti Secure Access Client with nZTA), and a description of the tools you can use to monitor your nZTA services (see Using the Insights Menu to Monitor User Activity and Service Usage).