ZTA Supported Features
- Introduction
Introduction
Ivanti provides a ZTA-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 ZTA services, by default, through an on-demand connection basis and can handle multiple simultaneous PZTA and non-PZTA connections. To learn more, see On-Demand and Simultaneous Connection Handling.
Ivanti Secure Access Client maintains communication with the PZTA 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 PZTA, see Enrolling a User Device.
Enrolling for nZTA Connections
On installing Ivanti Secure Access Client, the user can configure an nZTA connection using the same process used for other, existing connections (VPN Connections). To create an nZTA connection, compatible Ivanti Secure Access Client versions offer a specific connection type: “Zero Trust Access”.
The tenant administrator must supply the nZTA enrollment URL to their users to create the new nZTA connection.
For Mobile Application users, when using default enrolment URL, ensure you omit “/login/enrol” at the end of the URL.
Adding a Connection
To add a new nZTA connection:
- Click
. Enter the enrollment URL. The Add Connection dialog box opens.
- Enter the enrollment URL and click Submit.
- The network type auto populates as Zero Trust Access.
- For Name, specify a descriptive name for this connection. The name you specify appears in the Ivanti Secure Access Client interface.
- For Server URL, enter the nZTA controller URL as provided by the administrator.
- Click Add to save your new connection and the connection displays in the Home page.
- Click Enroll to initiate the enrollment to nZTA.
- On Home page, swipe the connection to Enroll and initiate a connection to the network. Enter the credentials to complete the connection.
Deleting a Connection
To delete an nZTA connection:
- Click the connection to select it.
- Click vertical three dots (
), and then select Delete.
- Confirm to the prompt to delete the connection.
Enrolling First Time Users
When enrolling a new device, an authorized user contacts the PZTA Controller 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 PZTA Gateway serving the resource set the client is authorized to view.
Enrolling Existing Users
After you have enrolled the new device, Ivanti Secure Access Client is installed and configured with the policies and settings relevant to the device type. Your application and resource access rights should be duplicated to the new device.
If a user device is currently using a Beta version of the ZTA-ready Ivanti Secure Access Client, Ivanti advises to remove the ZTA connection from Ivanti Secure Access Client and to re-perform the enrollment procedure through a web browser. For more details, see your support representative.
Authentication Methods and Policies
You can create authentication methods and apply them to the authentication policies you define in your Ivanti Neurons for Zero Trust Access (nZTA) deployment. You then apply an authentication policy, together with user rules, to a user group. A user group forms part of a Secure Access Policy.
nZTA supports the following types of authentication methods:
- Local authentication: An authentication system that is internal to the Controller. You must create all users manually on the Controller, and update any required authentication policies. If you are configuring Multi-Factor Authentication (MFA) in your deployment, you can configure local user authentication as either the primary or secondary authentication method.
- Azure AD SAML authentication: An existing remote SAML authentication system based on an Azure AD server.
- On-premICSSAML authentication: An existing remote SAML authentication system based on an on-premises ICS server.
- Okta SAML authentication: An existing remote SAML authentication system based on Okta.
- PingID SAML authentication: An existing remote SAML authentication system based on PingID.
- TOTP authentication: Time-based One Time Password (TOTP) authentication as a secondary mechanism in Multi-Factor Authentication deployments.
For details, see Working with User Authentication.
Dynamic Policy Update and CARTA
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 details, see Dynamic Policy Update and CARTA.
On-Demand and Simultaneous Connection Handling
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. For details, see On-Demand and Simultaneous Connection Handling.
Integrating NMDM with nZTA
This feature supports the compliance check for mobile devices during log-in and application access. For details, see Integrating Ivanti Neurons for MDM with nZTA.