--- title: Overview of Ivanti Neurons for Zero Trust Access slug: ps/help/en_us/nsa/22x/nsa-zta/ag/1000 docTags: createdAt: 2026-07-22T14:00:49.475Z --- - [Securing a Diverse Application Infrastructure](docId\:l_5jA2G89IAVU6vx7XKKi) - [Hyper-Converged Zero-Trust Access](docId\:l_5jA2G89IAVU6vx7XKKi) - [An Overview of Ivanti Neurons for Zero Trust Access](docId\:l_5jA2G89IAVU6vx7XKKi) - [Deploying and Using nZTA](docId\:l_5jA2G89IAVU6vx7XKKi) - [Deploying Gateways](docId\:l_5jA2G89IAVU6vx7XKKi) - [Defining User Authentication](docId\:l_5jA2G89IAVU6vx7XKKi) - [Publishing Applications](docId\:l_5jA2G89IAVU6vx7XKKi) - [Enrolling a User Device](docId\:l_5jA2G89IAVU6vx7XKKi) - [Summary of Steps to Configure Your nZTA Deployment](docId\:l_5jA2G89IAVU6vx7XKKi) # 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) - 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: - The current number of compliant users or devices - Application usage levels both in the cloud and on-premise - Visibility of any abnormal or compliance issues # 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 Gateway*s 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 - Users continue to use existing VPN connection profiles through *Ivanti Secure Access Client*, while incorporating new *nZTA* profiles to access your managed application infrastructure # 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. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/DL2kvRPmxInJmsbJVev5p_4dimensions.png" position="flex-start" size="80" width="1988" height="486" initialPath="img/4dimensions.png" githubPath="img/4dimensions.png" showCaption="false"} :::Paragraph{indent="1"} Four-dimensional authentication policy control ::: # 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. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/TPxNS_m4qGWcCUdwPavnQ_topology.png" position="flex-start" size="80" width="1958" height="1099" initialPath="img/topology.png" githubPath="img/topology.png" showCaption="false"} :::Paragraph{indent="1"} 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 Gateway*s 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. :::hint{type="info"} To learn more about using *Ivanti Secure Access Client* with *nZTA*, see [Enrolling Mobile/Desktop Clients](docId\:xlYYRE32DuERIDPt7Y8Ep) and [Using Ivanti Secure Access Client with nZTA](docId\:LOWTLfGQBiadNKrcw9BlV). ::: After you have defined your secure access policy, or policies, the *Controller* automatically synchronizes the configuration out to your *nZTA Gateway*s. 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: - Define and deploy *nZTA Gateway*s - 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 To login to the Tenant Admin Portal, see [Logging in as a Tenant Administrator](docId\:qAQLPFWfOt_GYC0QQw64z). # 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 Gateway*s - Ivanti Connect Secure (ICS) Gateways This guide describes how to install and configure *nZTA Gateway*s. 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 Gateway*s running on Microsoft Azure, Amazon Web Services (AWS), and VMware vSphere. *Ivanti* provides template images for each environment. :::hint{type="info"} To obtain the latest *nZTA Gateway* virtual machine template images, see the Release Notes. ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/AWAB6QQHYcXEpG8kbZRWZ_gateways.png" alt="To obtain the latest ZTA Gateway virtual machine template images, see the Release Notes." position="flex-start" size="80" width="1775" height="1266" initialPath="img/gateways.png" githubPath="img/gateways.png" showCaption="false"} :::Paragraph{indent="1"} Deploying *nZTA Gateway*s 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*. :::hint{type="info"} 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 Gateway*s, 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. :::hint{type="info"} 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 Gateway*s. To learn more about the process of creating and managing your *nZTA Gateway*s, including network interface and subnet requirements, see [Working with Gateways](docId\:odDr4Z3VrHMCgVhHAWv7j). ## 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](docId\:l_5jA2G89IAVU6vx7XKKi). 2. You deploy a load-balancer to route traffic to the Gateways, see [Using an Administrator-Deployed Load-Balancer](docId\:l_5jA2G89IAVU6vx7XKKi). 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](docId\:l_5jA2G89IAVU6vx7XKKi). :::hint{type="info"} To use active/standby and geo-proximity traffic distribution features with your *nZTA* deployment, your end-users must be running *Ivanti Secure Access Client* versions supported for use with *nZTA* version 21.3.2 or later. To learn more about supported client versions, see the *Release Notes*. ::: ## 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. :::hint{type="info"} 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. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/ITh89dKS9iS7XR8O92e6Z_gatewayhacgs.png" position="flex-start" size="80" width="2265" height="1274" initialPath="img/gatewayha_cgs.png" githubPath="img/gatewayha_cgs.png" showCaption="false"} :::Paragraph{indent="1"} Using *Controller* Gateway Selection with Gateways over multiple locations ::: ## 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. :::hint{type="info"} When using vTM for load-balancing, *Ivanti* recommends you configure the following settings in the vTM Admin UI to ensure proper fail-over functionality: ::: :::Paragraph{listStyleType="decimal" indent="2"} 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. ::: :::Paragraph{listStyleType="decimal" listStart="2" indent="2"} Click **Services > Pools** and edit your designated HTTPS pool. In the pool configuration, enable the following settings: ::: :::Paragraph{listStyleType="disc" indent="3"} 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. ::: :::Paragraph{listStyleType="disc" indent="3"} 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](docId\:odDr4Z3VrHMCgVhHAWv7j)). :::hint{type="info"} *nZTA* supports Gateway health monitoring using TCP port 443. ::: ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/4JjblHtNefrehvrWUXt5N_gatewayha.png" alt="Deploying a pair of Gateways for high availability" position="flex-start" size="80" width="1676" height="802" initialPath="img/gatewayha.png" githubPath="img/gatewayha.png" showCaption="false"} Deploying a pair of Gateways for high availability :::hint{type="info"} 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. :::Paragraph{indent="1"} The global load-balancer should be configured to manage an FQDN and resolve it to the public IP address of the optimal Gateway instance. To use the global load-balancer, add the FQDN managed by the global load-balancer to the **load-balancer** field of your Gateway Group configuration. ::: ## 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*. To learn more about configuring a Gateway Group, see [Working with Gateways](docId\:odDr4Z3VrHMCgVhHAWv7j). ## 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": ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/M0EyNf7B80LdzlQijcVaO_awstargetgroup.png" position="flex-start" size="80" width="2676" height="832" initialPath="img/awstargetgroup.png" githubPath="img/awstargetgroup.png" showCaption="false"} :::Paragraph{indent="1"} Setting Target Type in a Target Group ::: # 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*. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/YjZ3Ma6gkZsq3rDa3RwoB_userauth.png" position="flex-start" size="80" width="1902" height="1206" initialPath="img/userauth.png" githubPath="img/userauth.png" showCaption="false"} :::Paragraph{indent="1"} 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. - To read more about authentication methods, see [Creating User Authentication Methods](docId\:l_5jA2G89IAVU6vx7XKKi). - To read more about authentication policies, see [Using User Authentication Policies](docId\:l_5jA2G89IAVU6vx7XKKi). - To read more about user rules and groups, see [Defining User Authentication Rules and Groups](docId\:l_5jA2G89IAVU6vx7XKKi). ## Creating User Authentication Methods *nZTA* supports user authentication through the following methods: - local authentication - SAML authentication (through Azure AD or a custom defined service) - Time-based One Time Password (TOTP) authentication ### 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. :::hint{type="info"} *nZTA* supports the use of Local Authentication as a *primary* or *secondary* authentication mechanism. ::: To learn more about defining local authenticators in *nZTA*, see [Workflow: Creating a Local Authentication Policy](docId\:l_5jA2G89IAVU6vx7XKKi). ### 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. :::hint{type="info"} *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. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/2oSBTBg-pPgciOeqM8L-2_samlauth.png" position="flex-start" size="80" width="1552" height="560" initialPath="img/saml_auth.png" githubPath="img/saml_auth.png" showCaption="false"} :::Paragraph{indent="1"} 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. :::hint{type="info"} 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. To learn more about configuring SAML authenticators in *nZTA*, see [Working with User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ### 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. :::hint{type="info"} *nZTA* supports the use of TOTP in Multi-Factor Authentication as a *secondary* authentication mechanism only. ::: To learn more about defining TOTP authenticators for use in *nZTA*, see [Workflow: Adding TOTP to an Authentication Policy](docId\:l_5jA2G89IAVU6vx7XKKi). ## 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](docId\:l_5jA2G89IAVU6vx7XKKi), and cover the primary scenarios for authenticating user connections: - User enrollment - User sign-in - Administrator sign-in :::hint{type="info"} *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. ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/ksIBAUViN8AcY8qhnL2_d_userpolicies.png" position="flex-start" size="80" width="2042" height="696" initialPath="img/userpolicies.png" githubPath="img/userpolicies.png" showCaption="false"} :::Paragraph{indent="1"} 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. :::hint{type="info"} 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. To establish additional authentication endpoints for specific user groups, you can add *custom* authentication policies. To learn more, see [Adding Custom Authentication Policies](docId\:l_5jA2G89IAVU6vx7XKKi). ## 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: :::hint{type="info"} - **Enrollment Users**: This policy is intended for enrollment of new end-user devices. - **Users**: This policy is intended as the sign-in endpoint for enrolled devices. - **Administrators**: This policy is intended as the authentication endpoint for administrator-level sign-in to the *Controller*. ::: :::hint{type="info"} 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://.com/login/testuser`). This automatically redirects to `https://.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. :::hint{type="info"} 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](docId\:l_5jA2G89IAVU6vx7XKKi). To learn more about creating user authentication policies, see [Working with User Authentication](docId\:NJOnS_n7fVj7YPwBgqwRy). ## 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. :::hint{type="info"} 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](docId\:l_5jA2G89IAVU6vx7XKKi)), 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](docId\:l_5jA2G89IAVU6vx7XKKi). 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*. To learn more about defining User Rules and Groups, see [Creating User Rules and User Groups](docId\:l_5jA2G89IAVU6vx7XKKi). # 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](docId\:l_5jA2G89IAVU6vx7XKKi). ::Image[]{src="https://api.archbee.com/api/optimize/wxZG1KsS4xNkVZYoiu_o9/z1EJeTtT2FzezYeCrhadU_sap.png" position="flex-start" size="80" width="1805" height="1305" initialPath="img/sap.png" githubPath="img/sap.png" showCaption="false"} :::Paragraph{indent="1"} 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. The portal provides a step-by-step workflow to enable you to define and publish your secure access policy in one process. For more information on the **Create Secure Access Policy** workflow, see [Summary of Steps to Configure Your nZTA Deployment](docId\:l_5jA2G89IAVU6vx7XKKi). ## 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*. :::hint{type="info"} 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: | URI Scheme | Example(s) | | ------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | http\://\\[:\]\[/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\://\\[:\]\[/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\://\\[:\], tcp\://\\[:\], tcp\://\\[:\], tcp\://\\[:\*] | 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\://\\[:\], udp\://\\[:\], udp\://\\[:\], udp\://\\[:\*] | 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://\\[:\] | ssh://example.com, ssh://example.com:22, ssh://192.0.2.0, ssh://192.0.2.0:22 | | rdp\://\\[:\] | rdp\://example.com, rdp\://example.com:3389, rdp\://192.0.2.0, rdp\://192.0.2.0:3389 | | ica://\ | ica://example.com, ica://192.0.2.0 | | \:\ | www\.example.com:9090 | | \:\,\\[,...] | www\.example.com:9090,9091,9092 | | \:\-\ | www\.example.com:9090-9099 | | \:\* | www\.example.com:\* | | \ | 192.0.2.0/8, 192.0.2.0/255.0.0.0 | | \\[/\] | 192.0.2.1, 192.0.2.1/32, 192.0.2.1/255.255.255.255 | :::hint{type="info"} 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. :::hint{type="info"} 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](docId\:l_5jA2G89IAVU6vx7XKKi). To learn more about the process of creating applications and application groups, see [Adding Applications to the Controller](docId\:l_5jA2G89IAVU6vx7XKKi). ### 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](docId\:l_5jA2G89IAVU6vx7XKKi). 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](docId\:l_5jA2G89IAVU6vx7XKKi). To learn more about the process of defining user rules and rule groups, see [Creating User Rules and User Groups](docId\:l_5jA2G89IAVU6vx7XKKi). ## 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 Gateway*s 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. :::hint{type="info"} 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](docId\:l_5jA2G89IAVU6vx7XKKi). - A first time *nZTA* user, with no previous Pulse Secure or *Ivanti* software installed, see [First Time Users](docId\:l_5jA2G89IAVU6vx7XKKi). - An existing *nZTA* user enrolling a new device, or upgrading a previous version of *Ivanti Secure Access Client*, see [Existing nZTA Users](docId\:l_5jA2G89IAVU6vx7XKKi). 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](docId\:xlYYRE32DuERIDPt7Y8Ep). To learn more about using mobile and desktop clients with *nZTA*, see [Using Ivanti Secure Access Client with nZTA](docId\:LOWTLfGQBiadNKrcw9BlV) and [Enrolling Mobile/Desktop Clients](docId\:xlYYRE32DuERIDPt7Y8Ep). ## 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](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**". The tenant admin must then supply the *access URL* specified in the relevant user sign-in authentication policy to their users to create the new *nZTA* connection. To learn more about authentication policies, see [Using User Authentication Policies](docId\:l_5jA2G89IAVU6vx7XKKi). ## 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. After *Ivanti Secure Access Client* is installed, a secure connection request is attempted with the *Controller*. The request is validated against the designated authentication policy applicable to that combination of user and device and, where successful, a connection profile is downloaded to the client. This profile enables *Ivanti Secure Access Client* to set up a secure tunnel directly to the *nZTA Gateway* serving the resource set the client is authorized to view. ## 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. :::hint{type="info"} 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. :::hint{type="info"} 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 Gateway*s 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](docId\:xlYYRE32DuERIDPt7Y8Ep)), usage (see [Using Ivanti Secure Access Client with nZTA](docId\:LOWTLfGQBiadNKrcw9BlV)), 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](docId:9pR-GUBlUQ_Ko0B6yMLkA)).