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:

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:

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:

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.

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.

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.

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:

To login to the Tenant Admin Portal, see Logging in as a Tenant Administrator.

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:

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.

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.

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.

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.

To learn more about the process of creating and managing your nZTA Gateways, including network interface and subnet requirements, see Working with Gateways.

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:

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

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.

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

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.

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

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).

Deploying a pair of Gateways for high availability

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

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:

To learn more about configuring a Gateway Group, see Working with Gateways.

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":

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.

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.

nZTA supports user authentication through the following methods:

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.

To learn more about defining local authenticators in nZTA, see Workflow: Creating a Local Authentication Policy.

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:

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.

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.

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.

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.

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.

To learn more about defining TOTP authenticators for use in nZTA, see Workflow: Adding TOTP to an Authentication Policy.

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:

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

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:

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.

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:

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:

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.

To learn more about creating user authentication policies, see Working with User Authentication.

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.

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.

To learn more about defining User Rules and Groups, see Creating User Rules and User Groups.

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.

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.

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.

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

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.

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.

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.

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.

To learn more about the process of defining user rules and rule groups, see Creating User Rules and User Groups.

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

Examples of compliance include:

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:

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:

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.

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

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.

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".

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.

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 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:

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.

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:

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).