Using Ivanti Secure Access Client with nZTA¶
Introduction¶
Ivanti provides a nZTA-ready version of the Ivanti Secure Access Client software required for end-user devices to be able to connect to your secure applications and resources.
Ivanti Secure Access Client connects to nZTA services, by default, through an on-demand connection basis and can handle multiple simultaneous nZTA and non-nZTA connections. To learn more, see On-Demand and Simultaneous Connection Handling.
Ivanti Secure Access Client maintains communication with the Controller to continuously-enable synchronization of policy and configuration updates. Through this mechanism, user requests to access resources and applications are subject to continuous assessment for risk and authorization. For more details, see Dynamic Policy Update and CARTA.
To learn more about enrolling user devices for use with nZTA, see Enrolling a User Device.
On-Demand and Simultaneous Connection Handling¶
While active, Ivanti Secure Access Client maintains two connection channels for nZTA services, a control channel to the Controller, and a data channel to your ZTA Gateways. For more details on networking considerations when deploying ZTA Gateways, see Working with Gateways.
The control channel connection to the Controller is activated when Ivanti Secure Access Client is started up and remains in an always-on state, silently in the background. If Ivanti Secure Access Client is able to locate a valid session cookie from an earlier session, the connection is re-established automatically. If no valid cookie is present, Ivanti Secure Access Client requests re-authentication from the user. The control channel is terminated when Ivanti Secure Access Client is shut down.
Ivanti Secure Access Client user sessions with a ZTA Gateway are subject to the following default timeout values:
5 minutes idle timeout: If Ivanti Secure Access Client does not receive any traffic within this time period, the data channel to the connected Gateway is terminated, but the user session information is retained. If the user attempts the access the same resource(s) after this time (but before the maximum session timeout), the Gateway restores the data channel using the session information it currently holds.
60 minutes idle timeout: If a ZTA Gateway receives no traffic from a connected client within this time period, the Gateway deletes the user session and instructs the Controller to do the same. If the user attempts to access the same resource(s) after this time, Ivanti Secure Access Client resumes the session with the Gateway automatically using cached credentials. However, if a Single Logout URL is specified in the SAML authentication methods covering user enrollment and sign-in, the user must re-authenticate manually for the connection to resume (see Using SAML Single Logout to Force User Authentication).
Note
User sessions for client connections with other Gateways are unaffected.
720 minutes session timeout: If the user session reaches this maximum length, the session is terminated and re-authentication is requested from the client.
These values are the default settings. To configure custom idle timeout and max session length values for your user sessions, see Configuring Session Timeouts.
Ivanti Secure Access Client creates data channel connections to ZTA Gateways as an on-demand service. That is, connections to resources and applications controlled by ZTA Gateways become active only when required, and the connection is suspended after a period of inactivity. The user remains unaware of the connection state, unless re-authentication becomes necessary. As a user makes a request for a resource, Ivanti Secure Access Client transitions automatically from disconnected to connected. The connection remains in this state for the duration of the session, or until one of the following events occurs:
An idle time-out occurs (after 5 minutes)
The connection is actively placed in a disconnected state
Ivanti Secure Access Client is shut down
To avoid the data channel being reconnected unnecessarily, non-nZTA DNS traffic is redirected to the device’s physical network adapter.
Applicable Ivanti Secure Access Client versions can manage simultaneous connections with the Controller, and with other Ivanti services such as Ivanti Connect Secure (ICS). While ICS connections must be activated and deactivated by the user, connections to nZTA are provided on-demand, as mentioned. Therefore, a nZTA connection in the Ivanti Secure Access Client does not provide the same Connect and Disconnect controls. Instead, nZTA connections include only a ZTA button to provide access to the nZTA Applications page. If this button is active, the connection to the Controller has been established. If the button is inactive, the connection to the Controller has not yet been established, or a communication problem has occurred. In this case, access to your applications is prevented.
In a simultaneous dual connection scenario:
The standard VPN connection must be started first. Then, the nZTA VPN connection can be started.
If the nZTA VPN connection is started first, a standard VPN connection cannot be started afterwards if a default Gateway is in use, see Using Application Discovery with Ivanti Secure Access Client.
All requests from applications referenced in secure access policies are handled by ZTA Gateways. All other requests will be processed over the standard VPN outside nZTA , and will potentially be insecure.
When simultaneous dual VPN connections are active, application discovery using a default Gateway is not supported.
Note
Simultaneous dual connections are not currently supported on Linux clients.
Note
When using simultaneous dual connections, if the standard VPN is subsequently disabled, application discovery and a default Gateway will be activated automatically if configured. Currently, a default Gateway can only be utilized by requests from applications on macOS/Windows desktop devices.
When running active connections to both nZTA and ICS simultaneously, note that the following ICS features are not supported:
Route Monitoring
Traffic Enforcement
Stealth Mode
Always on VPN/LockDown
Location awareness
IPv6 support
Note
On-demand connections are not currently supported on Linux clients.
Resource Precedence Over Simultaneous Connections¶
In some cases, the simultaneous connection handling feature in Ivanti Secure Access Client can mean that FQDN-based or IP address-based resources can be configured across multiple nZTA and non-ZTA Gateways (such as ICS) simultaneously. Where such conflicts occurs, Ivanti Secure Access Client evaluates the order of precedence before establishing the connection.
The following table describes the order of precedence from highest to lowest:
Priority |
Order of Application Precedence |
Remarks |
|---|---|---|
1 |
nZTA FQDN resource |
nZTA FQDN resources have the highest precedence |
2 |
nZTA IP address resource - with Deny Policy |
|
3 |
nZTA IP address resource - with Allow Policy |
|
4 |
Non-nZTA FQDN/IP Address resources |
Non-nZTA resources have the lowest precedence in simultaneous connection handling mode |
The following table describes various resource conflict use-cases and the resolution applied by nZTA based on the above order of precedence:
Use Case |
Resource Conflict |
Resolution |
|---|---|---|
1 |
A nZTA FQDN resource conflicts with a nZTA IP Allow resource or nZTA IP Deny resource. |
The nZTA FQDN resource is given precedence. |
2 |
A nZTA IP Deny resource conflicts with a nZTA IP Allow resource. |
The nZTA IP Deny resource is given precedence. |
3 |
A nZTA IP Deny resource through one ZTA Gateway with a nZTA IP Deny Resource in another ZTA Gateway. |
The first ZTA Gateway IP resource takes effect as both are of same precedence. |
4 |
A nZTA IP Allow resource through one ZTA Gateway with a nZTA IP Allow resource in another ZTA Gateway. |
The first ZTA Gateway IP resource takes effect as both are of same precedence. |
5 |
A nZTA FQDN resource conflicts with a non-nZTA FQDN or IP resource. |
The nZTA FQDN resource is given precedence. |
6 |
A nZTA IP Deny or Allow resource conflicts with a non-nZTA IP resource. |
The nZTA IP resource is given precedence. |
7 |
A nZTA single IP resource is conflicted to a nZTA subnet range of IP addresses. |
Both routes are added to the client device routing table and the Operating System behavior is leveraged to choose the longest prefix match. Routing is established based on this criteria. |
8 |
A nZTA single IP/subnet resource is conflicted to a non-nZTA subnet range of IP addresses |
Both routes are added to the client device routing table and the Operating System behavior is leveraged to choose the longest prefix match. Routing is established based on this criteria. |
9 |
A non-nZTA include FQDN resource is also configured as a nZTA FQDN resource. |
[Split tunnel] First connect to the non-nZTA endpoint, and then to the nZTA endpoint (establishing simultaneous connection handling mode). Then, access the resource. The nZTA FQDN is given precedence. |
10 |
A non-nZTA include FQDN Resource is also configured as a nZTA FQDN resource. |
[Split tunnel] First connect to the nZTA endpoint, and then connect to the non-nZTA endpoint (establishing simultaneous connection handling mode). Then, access the resource. The nZTA FQDN is given precedence. |
The following scenarios are exceptions and can result in unexpected behavior:
Case |
Resource Conflict |
Remarks |
|---|---|---|
1 |
A nZTA FQDN or IP resource conflicts with a DNS IP address |
Currently, precedence is not given to the DNS IP address configuration. This can result in unexpected behavior. |
2 |
A nZTA IP resource conflicts with local subnet routes in a non-nZTA connection with local subnet route precedence. |
The nZTA IP resource is given precedence and the non-nZTA endpoint does not operate as expected in simultaneous connection handling mode. |
3 |
A nZTA IP resource conflicts with a non-nZTA server URI. |
If the non-nZTA server URI is resolved to an IP address which is configured as a nZTA IP resource, traffic is directed through nZTA due to the higher precedence. |
Using SAML Single Logout to Force User Authentication¶
By default, Ivanti Secure Access Client attempts to re-authenticate a connection to a nZTA-controlled resource using cached credentials for the session. In other words, during a single valid session, a user is not required to re-enter their credentials each time the on-demand connection is reactivated following an idle timeout or manual disconnection.
Note
To learn more about on-demand client connections, see On-Demand and Simultaneous Connection Handling.
An organization might want to establish a policy of increased security for connecting devices, such that prior to reconnecting the user is required to re-authenticate manually with the SAML IdP. To support this, nZTA includes the ability to specify a single logout/sign-out URL in the SAML authentication method you use for user enrollment or login.
By specifying a Single Logout URL in your SAML user authentication methods, your users must re-enter their credentials each time the nZTA connection is re-established.
To add a Single Logout URL to an existing user authentication method:
Log into the Controller as a Tenant Admin, see Logging in as a Tenant Administrator.
From the nZTA menu, click the Secure Access icon, then select Manage Users > Authentication Servers.
The Authentication Servers page appears. This page lists all existing user authentication methods. For example:
FIGURE 258 User Authentication Methods¶
Click the three dots adjacent to the user authentication method you want to modify, and click Edit.
The Edit Authentication Method dialog appears.
Specify your Single Logout URL in the text box provided:
FIGURE 259 Adding a Single Logout URL to a SAML authentication method¶
Click Next, then Next again to view the Summary step.
To save your changes, click Save Changes.
Note
Conversely, to re-establish the default service behavior of not requiring manual authentication upon re-connection, repeat these steps and remove the Single Logout URL from your existing authentication method.
To learn more about configuring an authentication method, see Working with User Authentication.
Disabling the nZTA Connection¶
Ivanti Secure Access Client additionally provides the ability to actively disable the on-demand connection feature. Use of this facility disables the nZTA connection, avoiding the scenario where Ivanti Secure Access Client attempts to repeatedly request authentication even after the user might be unable to authenticate due to too many failed attempts, or where the user just does not require access to any nZTA-controlled resources during that session.
If a user attempts to request a nZTA-controlled resource during the period a nZTA connection is disabled, the request fails. Other Ivanti Secure Access Client connections are unaffected.
To disable a nZTA connection, use one of the following mechanisms:
For Ivanti Secure Access Client on macOS and Windows, click Disconnect in the Ivanti Secure Access Client connection list context menu. Right-click a nZTA connection profile to see the available options.
FIGURE 260 Manually disabling a nZTA connection through the Ivanti Secure Access Client connection list context menu¶
For Ivanti Secure Access Client on macOS and Windows, click Disconnect from the System Tray client icon. View the sub-menu for the nZTA connection you want to disconnect.
FIGURE 261 Manually disabling a nZTA connection through the Ivanti Secure Access Client System Tray control¶
For Ivanti Secure Access Client on macOS and Windows, click Disconnect through the Ivanti Secure Access Client application menu. Open Ivanti Secure Access Client and select the nZTA connection profile. Then click File > Connections > Disconnect.
FIGURE 262 Manually disabling a nZTA connection through the Ivanti Secure Access Client application menu¶
For Ivanti Secure Access Client on Android and iOS devices, use the Disconnect option in the Ivanti Secure Access Client application. Open Ivanti Secure Access Client, locate the nZTA connection profile, and tap the Disconnect button.
FIGURE 263 Manually disabling a nZTA connection through the Ivanti Secure Access Client application (Android device example)¶
By setting the nZTA connection to be disconnected, Ivanti Secure Access Client suspends both the control channel and the data channel (where either are active). If the control channel was previously logged-in to the Controller, this remains the case to facilitate session resumption through a subsequent reconnect.
Note
The disconnect feature is not activated by clicking or tapping Cancel in the nZTA authentication dialog. Canceling an authentication request triggers a timeout interval, after which Ivanti Secure Access Client re-displays the authentication dialog. The disconnect feature instead disables the authentication request process until the user manually reinstates it.
To reinstate the nZTA connection on macOS and Windows devices, use the Launch ZTA option in the Ivanti Secure Access Client system tray menu:
FIGURE 264 Restarting a nZTA connection through the Ivanti Secure Access Client System Tray menu (macOS and Windows variants)¶
To reinstate the nZTA connection on Android and iOS devices, tap the ZTA button in the nZTA connection profile in the Ivanti Secure Access Client application:
FIGURE 265 Restarting a nZTA connection through the Ivanti Secure Access Client application (Android device example)¶
Note
This method also works for macOS and Windows devices.
If the existing session cookie is still valid, the control channel is re-established. If the session is now invalid, Ivanti Secure Access Client prompts the user for their nZTA credentials as normal. On successful re-establishment of the nZTA session, the user is presented with the nZTA End User Portal in the default browser.
When restarting Ivanti Secure Access Client, nZTA connections default to being on-demand services. That is, a previously disabled nZTA connection is re-enabled when Ivanti Secure Access Client starts.
Dynamic Policy Update and CARTA¶
To complement the zero-trust approach, nZTA supports dynamic policy updates and CARTA (Continuous Adaptive Risk and Trust Assessment) for your end user devices. This framework establishes an approach of continuous assessment and updating of secure access policies on the client, without the requirement to disconnect and reconnect to establish an updated authorization posture.
As your policies, applications, and authentication configuration are updated by the administrator on the Controller, changes are synchronized out to client devices dynamically and take effect immediately. Ivanti Secure Access Client ensures that any application updates are applied and any new authentication requirements are met before continuing the session, providing the end user with a seamlessly-updated experience. This method ensures that Ivanti Secure Access Client is always updated at the point of change, and not just when establishing a connection to a ZTA Gateway to access an affected resource.
The CARTA implementation in Ivanti Secure Access Client means that the security posture of the end user is continuously assessed in conjunction with policies configured in the Controller, with allow or deny decisions enforced through dynamic assessment and updating of the current policy set. Where application access is denied or restricted, Ivanti Secure Access Client informs the user of any access restrictions or policy contravention at the point of use. For example, the nZTA Applications Home page updates to provide visual cues with applicable error messages whenever a specific application becomes unavailable:
FIGURE 266 Access restricted to the “myhealth” application¶
By hovering your pointer over the warning symbol in the inactive application, nZTA provides an explanatory message.
Furthermore, user attempts to access a restricted web resource in a browser trigger a CARTA response with Ivanti Secure Access Client presenting a pop-up resource blocked message:
FIGURE 267 Ivanti Secure Access Client prevents browser access to a particular web resource where a device policy has been breached¶
Note
Pop-up resource blocked messages are not currently supported on Linux clients.
Ivanti Secure Access Client implements a no-repeat interval for resource blocked messages of 2 minutes, to avoid a user repeatedly seeing the same pop-up message for every browser request for the same restricted resource. While the resource remains blocked to further access attempts, no further messages are displayed by Ivanti Secure Access Client until after 2 minutes has elapsed. You can force Ivanti Secure Access Client to continue hiding blocked resource messages indefinitely by right-clicking the connection in the Ivanti Secure Access Client dialog and selecting Disable Block Messages. To re-enable showing blocked resource messages, select Enable Block Messages.
Using Application Discovery with Ivanti Secure Access Client¶
nZTA directs requests for a specific application towards the ZTA Gateway that is defined in the secure access policy for the application. All other applications use any available communications channels on the device, which may not be secure.
nZTA includes a built-in application discovery secure access policy on the Controller. This feature enables requests from any application that is not covered by a defined secure access policy to be handled by a default ZTA Gateway. This also enables packet analysis to be conducted from the ZTA Gateway to assess the validity of the requests.
To learn more about configuring default ZTA Gateways and application discovery, see Configuring a Default Gateway for Application Discovery.
Note
Client version 21.1 is required to work with application discovery and a default Gateway.
Note
Currently, a default Gateway can only be utilized by requests from applications on macOS and Windows desktop devices.
To use application discovery on an enrolled macOS/Windows desktop device:
Start the Ivanti Secure Access Client app on the device.
Confirm the update of policy definitions if required.
Ensure that there are no other VPN connections running on the client.
Note
Simultaneous dual VPN connections are supported by nZTA, but this scenario does not support the use of a default Gateway, see On-Demand and Simultaneous Connection Handling.
Start the nZTA connection and log in with your credentials.
The nZTA connection starts, and available applications appear. Each listed application will use the gateway assigned by a secure access policy pushed from the Controller.
The default Gateway then handles all requests from applications on the macOS/Windows desktop device that are not referenced by any other secure access policy.
Note
If another VPN connection is already in operation when the user connects to nZTA from the client, the default gateway configuration is ignored, and application discovery is not supported on the device. The existing VPN will handle all unassigned application requests from the client device. When a second VPN handling unassigned requests is subsequently closed on a desktop client device, use of the default gateway is enabled automatically to support application discovery on the client device. The default gateway will then handle all unassigned requests from the client device.
Using an Existing Enterprise PKI¶
Note
This feature is also known as Bring Your Own Certificate (BYOC)
The Controller typically generates device certificates based on a trusted Certificate Authority (CA) for your end-user devices at the point of enrollment. The certificate chain and CA is installed on the device at enrollment and then the certificate is submitted for validation upon each connection to your nZTA service. Ivanti assumes that by default a tenant deployment is going to use this validation infrastructure.
However, an enterprise may wish to use its own Public Key Infrastructure (PKI) with a nZTA deployment where, for example, a security policy may require the use of internally-generated certificates. In this scenario, Ivanti enables customers to issue and manage their own end-user device certificates (for example, through a Mobile Device Management type application), and to instruct the Controller to use an enterprise-provided CA when validating user sessions.
Use of BYOC is subject to the following limitations:
Support is limited to Windows and macOS devices only, using Ivanti Secure Access Client version 9.1R13-12191 and later.
Gateways are restricted to using only nZTA-generated certificates.
Each end-user device must be provided with its own unique certificate. nZTA does not support certificate reuse across multiple devices.
Browser-based enrollment is not supported in this scenario. Users must enroll devices by creating a new nZTA connection from within Ivanti Secure Access Client.
If a certificate expires or is revoked, an affected client device must be un-enrolled and then re-enrolled before a replacement certificate can be used.
If you plan to add a custom domain to your subscription (see Specifying a Custom Domain), make sure you add all required certificates before you configure the custom domain.
To use your own PKI with nZTA, you must:
Request a BYOC subscription from Ivanti.
Share the required CA certificates with the Ivanti DevOps organization, to allow them to configure your tenants accordingly.
Publish your device and CA certificates to your end-user devices.
For more information, contact your support representative.