Creating User Authentication Services¶
Ivanti Neurons for Zero Trust Access (nZTA) provides user authentication through authentication policies. Policies define the application of an authentication method for a specified access URL.
nZTA facilitates Multi-Factor Authentication (MFA) through the configuration of an optional secondary authentication method in a policy. MFA-based policies can use Local authentication or Time-based One Time Password (TOTP) as the secondary method.
nZTA also provides for the definition of user rules and user groups. Rules act as filters and define the basic criteria by which users’ credentials must match in order for authentication to proceed. Groups encapsulate an authentication policy with one or more user rules to provide a complete user authentication definition for your secure access policy. To learn more about creating user rules and user groups, see Creating User Rules and User Groups.
FIGURE 3 The relationship between user groups, rules, authentication policies and methods¶
nZTA provides three default/built-in authentication policies, suitable for the primary use-cases of administrative sign-in, user enrollment, and user sign-in:
Admin SignIn. This policy is used whenever admin users log in. That is, for connection requests to the */login/admin/ URL. It is referenced by the ALLADMINUSERS user rule, which associates it with the ADMINISTRATORS user rule group.
Enrollment SignIn. This policy can be used for enrolling a desktop/mobile client device. That is, for connection requests to the */login/enroll/ URL. It is referenced by the ALLENROLLMENTUSERS user rule, which associates it with the ENROLLMENT user rule group. You typically do not invite your users to connect directly to this endpoint, and instead link the policy to an equivalent user sign-in policy (such that users connecting an un-enrolled device to the sign-in policy are automatically redirected here).
User SignIn. This policy can be used as the primary connection endpoint for all user device sign-in and enrollment requests. That is, for connection requests to the */login/ URL. It is referenced by the ALLUSERS user rule, which associates it with the USERS user rule group. As mentioned above, users connecting an un-enrolled device to this policy are automatically redirected to the Enrollment SignIn policy.
These policies are fixed and cannot be deleted. However, you can edit them to reference specific authentication methods.
Note
MFA is supported for Admin SignIn and User SignIn policies only. To learn more, see the Tenant Admin Guide.
Furthermore, you can create additional custom authentication policies to enable bespoke authentication for specific groups of users or parts of your organization. Each policy should contain a unique access URL to which your users connect, and each should then be configured to link to authentication methods applicable for that purpose.
nZTA supports creating authentication services based on the following methods:
Local authentication: An authentication system that is internal to the Controller. You must create all users manually on the Controller, and configure any required authentication policies. See Workflow: Creating a Local Authentication Policy.
Azure AD SAML authentication: An existing remote SAML authentication system based on an Azure AD server. See Workflow: Creating a SAML Authentication Policy with Azure AD.
On-prem |PCS_shortname_bold| SAML authentication: An existing remote SAML authentication system based on an On-Prem ICS server. See Workflow: Creating a SAML Authentication Policy with On-Prem ICS.
Time-based One Time Password (TOTP) authentication: A one-time use password authenticator whereby a password (also known as a token) is generated by the Controller and the client from a shared secret key and the current time. TOTP is used as a secondary authentication method as part of a Multi-Factor Authentication deployment. See Workflow: Adding TOTP to an Authentication Policy.
Note
For further supported SAML authentication services, see the Tenant Admin Guide.
In each of the scenarios listed in this guide, to ensure that your users can access the authentication mechanism defined through this process, make sure your Secure Access Policies are configured with a User Group in which your newly-configured authentication policies are defined.
Workflow: Creating a Local Authentication Policy¶
Local authentication involves creating user records held locally in the Controller. Before you begin this process, make sure you have all user details (name and password) ready.
To configure a new local authentication method:
Log into the Tenant Admin Portal as an administrator.
From the nZTA menu, select 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 4 User Authentication Methods¶
Click Create Authentication Server.
A form appears that enables you to define the authentication method.
FIGURE 5 User Authentication Method Wizard¶
Note
At any point during this process, you can reset the form data by clicking Reset Fields.
Under Choose name and type:
Specify an Authentication Server Name.
Select the Authorization Type of Local.
Click Create User. The Create Local User dialog appears to show additional local authentication settings:
FIGURE 6 Adding local users to a new authentication method¶
Enter the following settings:
Specify a User Name, Full Name, and Email for the user.
Specify a Password and Confirm Password for the user.
(Optional) Select the Temporary Password check box if you want the user to change their password when they first log in.
Click Create User.
The user is added to the list of users.
Repeat the previous step for each required user.
Click Create Authentication Server.
The new local user authentication method is added to the list of methods and the process is complete.
After you have created your local authentication method, create or update your authentication policies with the new authentication method. In most cases, you need a minimum of two policies:
user enrollment
user sign-in
nZTA provides built-in policies to cover both basic cases. In addition, nZTA allows for the definition of custom policies to facilitate separate authentication endpoints for specific groups of users. To learn more, see the Tenant Admin Guide.
Repeat the following steps for each policy, starting with enrollment:
From the nZTA menu, click the Secure Access icon, then select Manage Users > User Policies.
The User Policies page appears. This page lists all existing user authentication policies.
FIGURE 7 User Authentication Policies¶
From this page, either create a new custom policy or edit an existing policy.
To add a new custom policy, click Create User Policy.
The Create Authentication Policy form appears.
FIGURE 8 Create Authentication Policy¶
Note
To learn more about how custom policies are used for user login and enrollment, see the Tenant Admin Guide.
Enter a Policy Name.
Enter a Login URL using the format */login/<path>/.
The URL must start with “*/login/” and cannot contain any special characters. <path> should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash):
In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the Controller. Example value: “*/login/saleslogin/”.
In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: “*/login/salesenroll/”.
Note
In some enrollment circumstances, such as when using a device pre-installed with an older version of Ivanti Secure Access Client, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see the Tenant Admin Guide.
(Optional) Enter a description for the authentication policy.
Select a User Type based on the intended authentication activity for this policy. Choose from:
Enrollment Users: Select this option to define the authentication endpoint for enrollment of new end-user devices. This endpoint is reserved for enrollment and not normally provided directly to users.
Users: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status).
Administrators: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the Controller only.
(for policies with a User Type of “Users” only): Select an Enrollment Policy from the drop-down list to be linked to this sign-in policy (as indicated):
FIGURE 9 Linking an enrollment policy to a user sign-in policy¶
This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled.
Under Policy Server Details, click Primary Auth Server, and choose the required authentication method for the policy from the drop-down list:
FIGURE 10 Selecting a primary authentication method for this policy¶
Alternatively, select Add New Server and create a new authentication method as per the steps described earlier in this section.
(Optional) Where a secondary method is required for Multi-Factor Authentication, repeat the previous step for Secondary Auth Server.
Note
Secondary authentication methods do not apply to Enrollment User type policies. The relevant field is hidden in this case.
Click Create User Policy to create the new policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in policy:
Click the three dots adjacent to the relevant policy and click Edit.
The Edit authentication policy form appears.
Note
For built-in authentication policies, all properties except Primary Auth Server and Secondary Auth Server (where applicable) are read-only.
Configure the primary and/or secondary authentication methods, as required:
Set the Primary Auth Server to be the new local user authentication method (indicated):
FIGURE 11 Editing the primary auth server¶
If you are configuring a policy for MFA, set the Secondary Auth Server to be the new local user authentication method (indicated):
FIGURE 12 Editing the Secondary auth server¶
Note
If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect.
Click Save.
The list of authentication policies updates.
Repeat until all required authentication policies are configured with the local authentication method.
Workflow: Creating a SAML Authentication Policy with Azure AD¶
Use this workflow to configure the Controller to act as a SAML Service Provider (SP) and engage Azure AD as a remote SAML Identity Provider (IdP).
As a minimum, configuring nZTA to use SAML authentication requires you to create separate SAML apps on the Azure AD platform for the following primary activities:
User enrollment
User sign-in
The Controller includes built-in default authentication policies for each of these purposes, and also includes the ability to create your own custom policies for separate authentication of specific user groups. You create an authentication method referencing one of the Azure AD SAML apps described above and then assign the method to an authentication policy of the same type (either the built-in policy, or one you create). Begin with enrollment, and then repeat the process for user sign-in.
Before you can start configuring nZTA, you must first perform the following steps in Azure AD:
Create a SAML app for the required activity (enrollment or sign-in) and define at least the following Basic SAML Configuration fields:
Identifier (Entity ID). This is the URL of the SAML endpoint on the Controller. This is the audience of the SAML response for IdP-initiated SSO. This cannot be left blank.
Reply URL (Assertion Consumer Service URL). This is the URL of the SAML consumer on the Controller. This is the destination URL in the SAML response for IdP-initiated SSO. This cannot be left blank.
Download the Federation metadata XML definition for the SAML app to your local workstation. Retain this file for later use.
Repeat these steps for each activity.
Note
For details on how to create SAML apps in Azure AD, see the Azure AD SAML documentation.
After you have completed the above prerequisite steps, you can proceed to configure the Controller. For each SAML app you just created, perform the following steps:
Log into the Tenant Admin Portal as an 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. nZTA includes two default authentication methods, one for admins and one for users.
FIGURE 13 User Authentication Methods¶
Click Create Authentication Server.
A form appears that enables you to define the authentication method.
FIGURE 14 User Authentication Method Wizard¶
Note
At any point during this process, you can reset the form data by clicking Reset Fields.
Under Choose name and type:
Specify an Authentication Server Name. For example: Enrollment or SignIn.
Select the Authorization Type of SAML (Azure AD).
The form expands to show additional settings:
FIGURE 15 Configuring SAML (Azure AD) authentication settings¶
(Optional) Specify a Single Logout URL. For more information, see the Tenant Admin Guide.
To provide your SAML IdP settings, select one of the following:
Select Upload to upload a digitally-signed (or unsigned) federation metadata XML definition file downloaded for this SAML activity from Azure AD. That is, for either user enrollment or user sign-in.
Note
By default, the Controller expects a signed metadata definition file. To allow an unsigned metadata file, select Allow Unsigned Metadata.
Then, upload your metadata file by clicking Upload a file here.
Select Enter Manually to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete.
Then, enter the following details:
FIGURE 16 Configuring SAML (Azure AD) IdP settings manually¶
The following minimum settings are required for your SAML authentication service to function correctly. Each setting relates to a value configured in the SAML application on your IdP. Contact your IdP administrator to obtain the relevant details:
IDP Entity ID: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider.
IDP SSO URL: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.IDP Slo Service: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format
https://<FQDN>. For more information, see the Tenant Admin Guide.User Name Template: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the Controller uses from the incoming assertion. For example:
<assertionNameDN.uid>, the NameID value where ICS is the IdP, the UID from X509SubjectName,<userAttr.attr>, attr from AttributeStatement attributes.IDP Signing Certificate: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key.
Note
If, at a later date, you need to modify the metadata definition file, edit the authentication method through the User Authentication page and repeat this step. However, note that federation metadata files from Azure AD are digitally-signed and so cannot be manually edited prior to upload back into nSA. This process supports replacing a definition file only with another digitally-signed and validated definition file.
Confirm that your settings are correct, then select Add to create the authentication method.
The new SAML user authentication method is added to the list of methods displayed in the User Authentication page, and the process completes.
After you have created your SAML authentication method, create or update your authentication policies with the new authentication method:
From the nZTA menu, click the Secure Access icon, then select Manage Users > User Policies.
The User Policies page appears. This page lists all existing user authentication policies.
FIGURE 17 User Authentication Policies¶
To learn more about the policies on this page, see the Tenant Admin Guide.
From this page, either create a new custom policy or edit an existing policy.
To add a new custom policy, click Crate User Policy.
The Create Authentication Policy form appears.
FIGURE 18 Add User Authentication¶
Note
At any point during this process, you can reset the form data by clicking Reset. You can also view existing authentication policies in a pop-up dialog by clicking View Auth Policies.
Note
To learn more about how custom policies are used for user login and enrollment, see the Tenant Admin Guide.
Enter a Policy Name.
Enter a Login URL using the format */login/<path>/.
The URL must start with “*/login/” and cannot contain any special characters. <path> should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash):
In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the Controller. Example value: “*/login/saleslogin/”.
In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: “*/login/salesenroll/”.
Note
In some enrollment circumstances, such as when using a device pre-installed with an older version of Ivanti Secure Access Client, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see the Tenant Admin Guide.
(Optional) Enter a description for the authentication policy.
Select a User Type based on the intended authentication activity for this policy. Choose from:
Enrollment Users: Select this option to define the authentication endpoint for enrollment of new end-user devices. This endpoint is reserved for enrollment and not normally provided directly to users.
Users: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status).
Administrators: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the Controller only.
(for policies with a User Type of “Users” only): Select an Enrollment Policy from the drop-down list to be linked to this sign-in policy (as indicated):
FIGURE 19 Linking an enrollment policy to a user sign-in policy¶
This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled. To learn more, see the Tenant Admin Guide.
Under Policy Server Details, click Primary Auth Server, and select the required authentication method from the drop-down list:
FIGURE 20 Selecting a primary authentication method for this policy¶
Alternatively, select Add New Server and create a new authentication method as per the steps described earlier in this section.
(Optional) Where a secondary method is required for Multi-Factor Authentication, repeat the previous step for Secondary Auth Server.
Note
Secondary authentication methods do not apply to Enrollment User type policies. The relevant field is hidden in this case.
Click Add to create the new policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in policy:
Click the three dots adjacent to the relevant policy and click Edit.
The Edit authentication policy form appears.
Note
For built-in authentication policies, all properties except Primary Auth Server and Secondary Auth Server (where applicable) are read-only.
Set the Primary Auth Server to be the new SAML user authentication method (indicated):
FIGURE 21 Editing the primary auth server¶
Note
SAML authentication can be used only as a Primary Auth Server. If you are using MFA, specify either a local authentiction or TOTP method as the Secondary Auth Server.
Note
If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect.
Select Save.
The list of authentication policies updates.
Repeat until all required authentication policies are updated.
At this point, the Controller uses the uploaded Federation Metadata to contact the SAML service. After this process completes, a Download function becomes available for each relevant policy. This metadata file is required to configure trusted communication with the remote SAML service:
Refresh your browser until the Download action is visible for the relevant policies.
Select the check box for the policy metadata you want to download and clear all other check boxes.
Click Download and save the metadata file.
Note
As mentioned previously, make sure you repeat this procedure for each required SAML app on your Azure AD platform. That is, you require separate XML metadata files for the enrollment authentication policy and the login authentication policy.
After you have configured a user authentication policy, you can configure the Azure AD platform with the SAML SP Metadata configuration of the Controller. You can also optionally configure the use of Multi-Factor Authentication with Azure AD. For details, see the Tenant Admin Guide.
Workflow: Creating a SAML Authentication Policy with On-Prem ICS¶
Use this workflow to configure the Controller to act as a SAML Service Provider (SP) and engage Ivanti Connect Secure (ICS) as a remote (or local) on-prem SAML Identity Provider (IdP).
Configuring nZTA to use SAML authentication requires you to create separate SAML apps on the on-premises ICS server for the following primary activities:
User enrollment
User sign-in
The Controller includes built-in default authentication policies for each of these purposes, and also includes the ability to create your own custom policies for separate authentication of specific user groups. You create an authentication method referencing one of the Azure AD SAML apps described above and then assign the method to an authentication policy of the same type (either the built-in policy, or one you create). Begin with enrollment, and then repeat the process for user sign-in.
Before you begin configuring the Controller, make sure you have configured your ICS instance to perform the function of a SAML IdP and obtained the IdP Metadata file necessary for uploading to nZTA. For full instructions, see the ICS documentation held at https://www.ivanti.com/support/product-documentation. A summary of the steps is also contained in the “Ivanti Neurons for Secure Access: Tenant Admin Guide”.
After you have obtained the IdP metadata files from ICS, configure nZTA to use SAML authentication by performing the following steps:
Note
You must complete these steps for each SAML app on your ICS server. That is, for both enrollment and sign-in.
Log into the Tenant Admin Portal as an 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. nZTA includes two default authentication methods, one for admins and one for users.
FIGURE 22 Authentication Servers¶
Click Create Authentication Server.
A form appears that enables you to define the authentication method.
FIGURE 23 User Authentication Method Wizard¶
Note
At any point during this process, you can reset the form data by clicking Reset Fields.
Under Choose name and type:
Specify an Authentication Server Name. For example: Enrollment or SignIn.
Select the Authorization Type of SAML (Custom).
The form expands to show additional settings:
FIGURE 24 Configuring SAML (Custom) authentication settings¶
(Optional) Specify a Single Logout URL. For more information, see the Tenant Admin Guide.
To provide your SAML IdP settings, select one of the following:
Select Upload to upload a digitally-signed (or unsigned) federation metadata XML definition file downloaded for this SAML activity from your IdP. That is, for either user enrollment or user sign-in.
Note
By default, the Controller expects a signed metadata definition file. To allow an unsigned metadata file, select Allow Unsigned Metadata.
Then, upload your metadata file by clicking Upload a file here.
Select Enter Manually to manually enter the required IdP SAML settings. Use this option in scenarios where a SAML federation metadata file is not available or incomplete.
Then, enter the following details:
FIGURE 25 Configuring SAML (Azure AD) IdP settings manually¶
IDP Entity ID: The entity ID is sent as the Issuer value in the SAML assertion generated by the IdP. Specify the Issuer value in assertions generated by the SAML identity provider.
IDP SSO URL: A URL provisioned by the SAML IdP to support service-provider-initiated Single Sign-On. Use the format
https://<FQDN>.IDP Slo Service: (Optional) A URL to specify the Single Log-Out/sign out endpoint if you want to force re-authentication for increased security. Use the format
https://<FQDN>. For more information, see the Tenant Admin Guide.User Name Template: Specify how the system is to derive the username from the SAML assertion. The default value can be used, or replaced with an alternative specifier that the Controller uses from the incoming assertion. For example:
<assertionNameDN.uid>, the NameID value where ICS is the IdP, the UID from X509SubjectName,<userAttr.attr>, attr from AttributeStatement attributes.IDP Signing Certificate: The signing certificate to be used with the SAML app on the IdP. Type or paste in the contents of your Base-64 encoded public key.
Note
If, at a later date, you need to replace the metadata definition file with a modified version, edit the authentication method through the User Authentication page and repeat this step. Either edit the existing metadata file and re-upload, or replace it completely with a new version. In both cases, however, make sure your metadata file is valid before uploading it through this process.
Confirm that your settings are correct, then select Add to create the authentication method.
The new SAML user authentication method is added to the list of methods displayed in the User Authentication page, and the process completes.
After you have created your SAML authentication method, create or update your authentication policies with the new authentication method.
From the nZTA menu, click the Secure Access icon, then select Manage Users > User Policies.
The User Policies page appears. This page lists all existing user authentication policies.
FIGURE 26 User Authentication Policies¶
To learn more about the policies on this page, see the Tenant Admin Guide.
From this page, either create a new custom policy or edit an existing policy. To add a new custom policy:
Click Create User Policy.
The Create Authentication Policy form appears.
FIGURE 27 Add User Authentication¶
Note
At any point during this process, you can reset the form data by clicking Reset. You can also view existing authentication policies in a pop-up dialog by clicking View Auth Policies.
Note
To learn more about how custom policies are used for user login and enrollment, see the Tenant Admin Guide.
Enter a Policy Name.
Enter a Login URL using the format */login/<path>/.
The URL must start with “*/login/” and cannot contain any special characters. <path> should be set to a unique value reflecting the endpoint URL you want to define for this authentication policy (appended with a backslash):
In the case of user sign-in policies, this is the URL endpoint (appended to the tenant FQDN) to which new users are invited to connect to enroll or sign-in a device with the Controller. Example value: “*/login/saleslogin/”.
In the case of user enrollment policies, this endpoint identifies the enrollment URL to which users are redirected if they attempt to connect to the equivalent sign-in policy with an un-enrolled device. In most cases, you do not advertise this endpoint to your users. Example value: “*/login/salesenroll/”.
Note
In some enrollment circumstances, such as when using a device pre-installed with an older version of Ivanti Secure Access Client, you connect directly to the enrollment policy endpoint to enroll the device. For more details, see the Tenant Admin Guide.
(Optional) Enter a description for the authentication policy.
Select a User Type based on the intended authentication activity for this policy. Choose from:
Enrollment Users: Select this option to define the authentication endpoint for enrollment of new end-user devices. This endpoint is reserved for enrollment and not normally provided directly to users.
Users: Select this option to define the user sign-in endpoint for enrolled devices. This is the endpoint that you provide to your users to access the service (regardless of enrollment status).
Administrators: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the Controller only.
(for policies with a User Type of “Users” only): Select an Enrollment Policy from the drop-down list to be linked to this sign-in policy (as indicated):
FIGURE 28 Linking an enrollment policy to a user sign-in policy¶
This is the enrollment policy to which a user is redirected if it is determined that the device is not yet enrolled.
Under Policy Server Details, click Primary Auth Server and choose the required authentication method for the policy from the drop-down list:
FIGURE 29 Selecting a primary authentication method for this policy¶
Alternatively, select Add New Server and create a new authentication method as per the steps described earlier in this section.
(Optional) Where a secondary method is required for Multi-Factor Authentication, repeat the previous step for Secondary Auth Server.
Note
Secondary authentication methods do not apply to Enrollment User type policies. The relevant field is hidden in this case.
Click Add to create the new policy.
The new policy is added to the list of authentication policies.
If you instead elect to update an existing custom or built-in policy:
Click the three dots adjacent to the relevant policy and click Edit.
The Edit authentication policy form appears.
Note
For built-in authentication policies, all properties except Primary Auth Server and Secondary Auth Server (where applicable) are read-only.
Set the Primary Auth Server to be the new SAML user authentication method (indicated):
FIGURE 30 Editing the primary auth server¶
Note
SAML authentication can be used only as a Primary Auth Server. If you are using MFA, specify either a local authentication or TOTP method as the Secondary Auth Server.
Note
If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect.
Click Save.
The list of authentication policies updates.
At this point, the Controller uses the uploaded metadata to contact the SAML service. After this process completes, a Download function becomes available for the policy. This metadata file is required to configure trusted communication with the remote SAML service. Perform the following steps:
Refresh your browser until the Download action is visible for the relevant policy.
Select the check box for the policy and clear all other check boxes.
Click Download and save the metadata file.
Note
Repeat these steps for each required SAML app on your On-Prem ICS server. That is, you require separate XML metadata files for the enrollment authentication policy and the login authentication policy.
After you have configured authentication policies, you can configure your ICS SAML app with the SP Metadata configuration of the Controller. You can optionally also configure the use of Multi-Factor Authentication with ICS. For more information, see the Tenant Admin Guide.
Workflow: Adding TOTP to an Authentication Policy¶
Note
This feature is supported for client and gateway versions applicable to release 22.2R1 and later only.
nZTA supports the use of Time-based One Time Password (TOTP) as a secondary authentication method in Multi-Factor Authentication deployments.
To use TOTP, first create a TOTP authentication method in nZTA and then associate it with your user sign-in authentication policies.
To ensure that your users can access the authentication mechanism defined in the policies you configure through this process, make sure your Secure Access Policies are configured with a User Group in which these authentication policies are defined. To learn more, see Creating a Secure Access Policy.
To configure a new TOTP authentication method:
Log into the Controller as a Tenant Admin.
From the nZTA menu, select 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 31 Authentication Servers¶
Select Create Authentication Server.
A form appears that enables you to define the authentication method.
FIGURE 32 Adding a new TOTP user authentication method¶
Note
At any point during this process, you can reset the form data by selecting Reset. You can also view existing authentication methods in a pop-up dialog by selecting View Auth Methods.
Under Choose name and type:
Specify an Authentication Server Name.
Select the Authorization Type of TOTP.
The form expands to show additional TOTP authentication settings:
FIGURE 33 Adding TOTP authentication settings¶
Enter the following settings:
Note
This release supports a Server Type of local only. This field is read-only.
No of Attempts: The maximum number of consecutive wrong attempts allowed before which the account is locked (minimum: 1 attempt, maximum: 5 attempts). To view user attempts and to unlock locked accounts, see Unlocking Locked User Accounts.
Custom message for registration page: A custom message to be shown on the new TOTP-user registration web page.
Allow Auto Unlock: When selected, a locked account is automatically unlocked after the specified Auto Unlock Period. (minimum: 10 minutes, maximum: 90 days).
Display QR code during User Registration: When selected, a QR code is displayed during user registration.
Disable Generation of Backup Codes: When selected, the Controller does not generate TOTP backup codes.
To create an authentication method based on these settings, select Add.
The new TOTP user authentication method is added to the list of methods and the process is complete.
After you have created your TOTP authentication method, create or update your user sign-in authentication policies with the new method. nZTA supports using TOTP only as secondary authentication, so make sure you have previously configured a primary authentication method before continuing this process.
Note
Secondary authentication methods do not apply to Enrollment User type policies. The relevant field is hidden in this case.
Complete the following steps for your user sign-in authentication policy:
From the nZTA menu, select the Secure Access icon, then select Manage Users > User Policies.
The User Policies page appears. This page lists all existing user authentication policies.
FIGURE 34 User Authentication Policies¶
To learn more about the policies on this page, see the Tenant Admin Guide.
Click the three dots adjacent to your desired user sign-in policy, then select Edit.
The Edit Authentication Policy form appears.
FIGURE 35 Selecting a secondary TOTP authentication method for this policy¶
For Secondary Auth Server, select your new TOTP authentication method from the drop-down list (as indicated).
Alternatively, select Add New Server and create a new authentication method as per the steps described earlier in this section.
Select Save to update the policy.
Note
If you configure a secondary authentication method in a policy that is currently in use, any active user sessions must be disconnected and reconnected for the changes to take effect.
Unlocking Locked User Accounts¶
After you have created a TOTP authentication method and assigned it to an active user authentication policy, you can use the authentication method configuration page to view users that have attempted authentication through TOTP. This information enables you to unlock locked user accounts, if required.
To access user attempt information, perform the following steps:
Select Secure Access > Manage Users > Authentication Servers.
Click the three dots adjacent to your TOTP authentication method, then select Edit.
At the bottom of the page, a Users table is presented:
FIGURE 36 Viewing the list of users who attempted TOTP authentication through this method¶
This table lists each user who has attempted to authenticate a device through TOTP, including the last attempt and last successful login times.
(Optional) If a user account is locked through too many consecutive failed authentication attempts (that exceed the value configured in No of Attempts), unlock the account by selecting the checkbox adjacent to the user entry and selecting UNLOCK. The user is then free to re-attempt authentication using valid authentication codes.
(Optional) To remove a user from the list, select the checkbox adjacent to the user entry and select RESET. This means a user must then re-register their device with the TOTP policy.
Note
Reset and unlock operations of individual users are supported only when the TOTP authentication method is associated with a user authentication policy. To reset or unlock all users in a disassociated TOTP authentication method, delete the TOTP authentication method itself.
Creating User Rules and User Groups¶
After your authentication policies and methods are established, you can set up any required user rules.
Each user rule identifies one or more users, either from a local authentication service or from an external SAML service.
You associate one or more user rules with an authentication policy to form a user group.
Creating User Rules¶
nSA includes three default user rules:
ALLADMINUSERS. This matches all users, and is referenced by the default ADMINISTRATORS user group, which associates it with the built-in Admin Signin authentication policy.
ALLENROLLMENTUSERS. This matches all users, and is referenced by the default ENROLLMENT user group, which associates it with the built-in Enrollment Signin authentication policy.
ALLUSERS. This matches all users, and is referenced by the default USERS user group, which associates it with the built-in User Signin authentication policy.
Note
To read more about default user groups or built-in authentication policies, see the Tenant Admin Guide.
This preset configuration of rules, groups, and policies is suitable for typical use cases involving whole-organization authorization needs. In other words, where you require only a single user authorization path that matches all users. For scenarios where you require more specific user authorization checks, you can create additional rules to match specific types of users.
When you create a rule, you select the user attribute with which you want this rule to test. nSA provides the following rule attribute types:
username: For local authentication methods, choose this attribute type to match against locally-defined user names.
SAML (Azure AD): For SAML authentication methods, choose this attribute type to match against user names or groups provided by the SAML service.
Custom: For SAML authentication methods, choose this attribute type to match against a custom SAML attribute expression.
To create a user rule:
From the nZTA menu, select the Secure Access icon, then select Manage Users > User Rules.
The User Rules page appears. This page lists all user rules.
Click Create User Rule.
The Create User Rule form appears.
FIGURE 37 Create User Rule¶
Note
At any point during this process, you can reset the form data by clicking Reset Fields.
Enter a Rule Name.
Click Select Attribute Type and select one of the available options:
Username: Matches user names in a local authentication method. When you select this option, you must then:
Select an Expression type, either Matching or Not Matching.
For the User value, enter a match expression for the selected Expression type. For the value:
A comma-separated list of items is supported where required.
Wildcard matches are supported.
Special characters are supported.
Single and double quotes are not supported.
Note
Ivanti recommends that a basic asterisk wildcard is not used when you intend to associate admin roles with user groups. Instead, a more-specific wildcard that only includes admin users is required in this case to prevent all users having total access rights.
SAML (Azure AD): Matches user names or groups in a SAML authentication method. When you select this option, you must then:
Select a SAML Attribute Type, either Username or Group.
For Attribute Value, enter a match expression for the selected SAML Attribute Type as a SAML expression.
Custom. Matches against a custom SAML attribute expression. When you select this option, use the Type or Create an Expression property to enter an attribute expression. Supported formats include:
For simple user attribute key-value matching, use the syntax
userAttr.<attr-key> [=|!=] <attr-value>. For example:- userAttr.memberOf = "CN=sales,DC=example,DC=com" - userAttr.mail = "[email protected]" - userAttr.realm = "Users" - userAttr.department != "example_department"
To match against attributes that can have multiple values associated with a single attribute key, use the syntax
samlMultiValAttr.<attr-key> [=|!=] (<list>). For example:- samlMultiValAttr.memberOf = ("CN=Employee,CN=Users,DC=example_demo,DC=com") - samlMultiValAttr.memberOf = ("CN=Users,DC=example_demo,DC=com")
Use brackets and AND/OR operators to construct logical compound expressions:
- userAttr.groups = ("Group1" or "Group2") - userAttr.realm = ("ztaqa") and samlMultiValAttr.memberOf = ("CN=sales,DC=uisdp,DC=com") - userAttr.realm = ("ztaqa") or samlMultiValAttr.memberOf = ("CN=sales,DC=uisdp,DC=com") - userAttr.realm != ("ztaqa") and samlMultiValAttr.memberOf = ("CN=sales,DC=uisdp,DC=com")
Click Create User Rule.
The new user rule is added to the list of user rules.
Repeat steps 3-6 for each required user rule.
After you have created all required user rules, you can create user groups, see Creating User Groups.
Creating User Groups¶
After you have created user rules (see Creating User Rules), you associate one or more user rules with an authentication policy to form a user group.
nSA includes three default user groups:
ADMINISTRATORS. This user group associates the default ALLADMINUSERS user rule with the built-in Admin Signin authentication policy.
ENROLLMENT. This user group associates the default ALLENROLLNMENTUSERS user rule with the built-in Enrollment Signin authentication policy.
USERS. This user group associates the default ALLUSERS user rule with the built-in User Signin authentication policy.
Note
To read more about built-in authentication policies, see the Tenant Admin Guide.
This preset configuration of rules, groups, and policies is suitable for typical use cases involving whole-organization authorization needs. In other words, where you require only a single user authorization path that matches all users. For scenarios where you require more specific user authorization checks, you can create additional user groups to make different associations of user rules and custom authentication policies.
To create a user group:
From the nZTA menu, click the Secure Access icon, then select Manage Users > User Groups.
The User Groups page appears. This page lists all user rule groups.
Click Create User Group.
A form appears to enable you to create the user group.
FIGURE 38 Create User Groups¶
Enter a User Group Name and an optional Description, then click Next.
Select each of the listed User Rules that are required in the user group, then click Next.
Select required authentication policy from the list, then click Next.
Review the summary and click Create.
The new user group appears in the User Groups list.
Repeat steps 2-7 to create all required user groups.
Next Steps¶
After you have configured your authentication methods and policies, and added them to your user groups, proceed to configure your nZTA Gateways, see Configuring Gateways.