NSA Administration

54 min

Scanning with Indicator of CompromiseScanning with Indicator of Compromise

Introduction

After you have logged into the NSA for the first time, you can create authentication methods and apply them to the authentication policies you define in your NSA deployment. You then apply an authentication policy, together with admin rules, to a admin group. A admin group forms part of a Secure Access Policy.

To view admin authentication methods currently defined on the NSA, see Viewing Admin Authentication Methods. To view user authentication policies, see Viewing Admin Authentication Policies.

This chapter includes workflows for configuring admin authentication according to each supported authentication type. NSA supports the following types:

Local authentication: An authentication system that is internal to the NSA. You must create all users manually on the NSA, and update 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 and SAML(Custom).

SMAL Custom: An customized remote SAML authentication system based on an on-premises ICS server. See Workflow: Creating a SAML Authentication Policy With Azure AD and SAML(Custom)

After you have created the required authentication method and updated your admin authentication policies, you create admin rules and admin groups, see Creating Admin Rules and Admin Groups

Optionally, you can associate each admin group with an admin role, see Associating Admin Groups with Admin Roles.

Viewing Admin Authentication Methods

To view the admin authentication methods defined on the NSA, click the Administration icon in the Ivanti Connect Secure menu, then select Admin Management > Authentication Servers.

The Authentication Servers page appears, showing all admin authentication methods:

From this page, you can:

Add a new authentication method by clicking Create Authentication Server.

Edit an existing authentication method by selecting its check box and clicking Actions > Edit. Make any required updates and save the changes.

Delete an unused authentication method by selecting its check box and clicking Actions > Delete. You must confirm the deletion.

View the configured attributes for a SAML authentication method, where that method is configured for use with an authentication policy. To do this, click the arrow indicator to the left of the method name, where shown.

Use the Advanced Filter to view the list based on Name or Authentication method.

Viewing Admin Authentication Policies

To view the user authentication policies defined on the NSA, click the Administration icon in the Ivanti Connect Secure menu, then select Admin Management > Admin Policies.

The Admin Policies page appears, showing all user authentication policies.

NSA provides 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.

This policy is fixed and cannot be deleted. However, you can edit to reference a specific authentication method.

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 an authentication method applicable for that purpose.

From this page, you can:

(For SAML authentication) Download policy metadata files that are required for external SAML enrollment or sign-in apps. To do this, select the check box for the required policy and click Download. Save the file to your local workstation.

View the configured attributes for a SAML-authenticated policy, where that policy is configured with a valid SAML authentication method. To do this, click the arrow indicator to the left of the policy name, where shown.

Add an authentication policy by clicking Create Admin Policy.

Edit an existing authentication policy by selecting its check box and clicking Actions > Edit. Make any required updates and save the changes.

Enable/Disable an admin policy.

Delete an unused authentication policy by selecting its check box and clicking Actions > Delete. You must confirm the deletion.

Use the Advanced Filter to view the list based on Name, Server, Server Type, Device Policy, Enroll Device Policy, or Access URL.

Creating Admin Policies

You can use the existing default polices or can create new policy and use the default admin policy.

To configure Admin Policy for users:

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Management.

In the Admin Management page, select Admin Policies.

Click Create Admin Policy.

Manage User Policy

Enter the Policy Name, Login URL using the format */login/<path>.

Select the User Type: Enrollment Users/ Users/Administrators.

Select the Device Policy from the drop-down menu. For example, Deny_Location.

There are a few exceptions while creating User Policies when user Type is Administrator. The following device policies are not applicable to Administrator user. - Any device policy having Risk Sense rule. - Any device policy having Time of Day rule. - Any device policy having combination of Location and Network rules.

Select the Auth Server.

Click Create Admin Policy.

Users can also edit the existing Default policy to include the Device policy during the enrollment sign-in/user authentication.

Edit User Policy

Make required changes and click Update Admin Policy.

Creating Admin Rules and Admin Groups

After your authentication method is established and associated with an authentication policy, you can set up any required admin rules and admin groups. A admin rule identifies one or more admin users based on a test against a selected attribute present in a admin credential or profile, checked against either a local authentication record or from a SAML authentication service. For information about creating admin rules, see Creating Admin Rules.

You associate one or more user rules with an authentication policy to form a user group (see Creating Admin Groups). Users requesting authorization for a service controlled by a Secure Access Policy must pass all the rules contained in the admin Group attached to the policy.

A admin group is required when defining a secure access policy. The admin group identifies the users and the authentication policy to which a secure access policy applies.

Optionally, you can associate each user group with an admin role, see Associating Admin Groups with Admin Roles.

Creating Admin Rules

Through admin rules, an admin can construct a test to provide authorization to only those users of a particular name, role, group, or some other stored attribute. In the rule configuration, you select the admin attribute on which you want a test to be performed.

NSA includes the following default admin rule:

ALLADMINUSERS. This matches all admin users, and is referenced by the default ADMINISTRATORS admin group, which associates it with the built-in Admin Signin authentication policy.

To read more about default admin groups, see Creating Admin Groups. To read more about built-in authentication policies, see Viewing Admin Authentication Policies.

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 admin user authorization path that matches all users. For scenarios where you require more specific admin user authorization checks, you can create additional rules to match specific types of users.

When you create a rule, you select the admin 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 admin rule:

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Management > Admin Rules. The Admin Rules page appears. This page lists all admin rules.

Click Add. The Add Admin Rule form appears.

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

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. The new admin rule is added to the list of admin rules.

Repeat steps 3-6 for each required user rule.

(Optional) Edit an existing admin rule by selecting its check box and then clicking Actions > Edit. Make any required updates and save the changes.

(Optional) Delete an unused admin rule by selecting its check box and then clicking Actions > Delete. You must confirm the deletion.

After you have created all required admin rules, you can create admin groups, see Creating Admin Groups.

Creating Admin Groups

After you have created admin rules (see Creating Admin Rules, you associate one or more admin rules with an authentication policy to form a Admin group.

Admin groups are one of the four dimensions of a Secure Access Policy.

NSA includes the following default user group:

ADMINISTRATORS. This admin group associates the default ALLADMINUSERS admin rule with the built-in Admin Signin authentication policy.

To read more about built-in authentication policies, see Viewing Admin Authentication Policies.

To create a admin group:

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Management > Admin Groups. The Admin Groups page appears. This page lists all admin rule groups.

Click Create Admin Group. A form appears to enable you to create the admin group.

Enter a Admin Group Name.

Click Select an Authentication Policy and select the required authentication policy.

Add a Description for the admin group. Click Next.

Select each of the listed Admin Rules that are required in the user group. Click Next.

Select each of the listed Admin Policies that are required in the user group. Click Next.

Verify the Summary page and click Create. The new admin group appears in the admin Groups list.

Repeat steps 2-7 to create all required user groups.

(Optional) To edit a listed admin group, select the corresponding check box and click Actions > Edit, and make any required updates.

(Optional) To delete an unused admin group, select the corresponding check box and click Actions > Delete, and then confirm the deletion.

(Optional) Use the Advanced Filter to list based on Name or Authentication Policy.

After you have created admin groups, you can optionally assign the admin group to an admin role, see Associating Admin Groups with Admin Roles

Associating Admin Groups with Admin Roles

An admin role defines the elements of the admin interface that an associated admin user group can access.

The current admin can only access an individual admin interface page/workflow if their admin group is associated with an admin role that permits it. The tasks they can perform within that displayed element depends on the permissions set within the admin role.

When you are using admin roles, Ivanti recommends that any admin rules for administrators does not use a basic asterisk wildcard, see Creating Admin Rules. Instead, a more-specific wildcard that only includes admin users is required in this case to prevent all users having total access rights.

The default admin roles are not created by the tenant admin using the NSA user interface. Rather, they are set up by the Ivanti DevOps team.

For example, the DevOps team might define the following admin roles:

The .Administrators admin role has access to all user interface elements (full read, create, update, delete rights).

The .Read-Only Administrators admin role has access to all user interface elements except workflows (read only).

The .Network Administrators admin role has access to Gateways and Insights (read only).

The .CxOs admin role has access to Insights only (read only).

For more information about your assigned admin roles, please contact Ivanti DevOps.

The Admin can view admin roles in the Administration > Admin Roles page, and associate each role with a single user group.

To associate a user group with an admin role:

Log into the NSA as a Tenant Admin.

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Roles. A list of Admin Roles appears. This includes default admin roles and custom admin roles (RBAC). For example:

Click Actions > Edit for the admin role you want to update. A dialog appears. For example:

Under Choose group, select the user group that you want the admin group to be associated with.

Click Save Changes.

(Optional) Repeat steps 3 to 5 for each admin role.

Role-based Access Control for Admin Users

With Role-based access control (RBAC), organizations can easily add admins and assign them specific roles, with differing levels of access to the NSA Admin Portal. In addition to an existing set of default roles, Administrators can now create custom granular roles for specific functions within the NSA admin portal.

The following examples illustrate how an organization can leverage role-based administration for a variety of scenarios.

To create a custom admin role:

Log into the NSA as a Tenant Admin, see Logging in to the Ivanti Neurons for Secure Access as a Tenant Admin.

From the Ivanti Connect Secure menu, select Administration, then select Admin Roles.

In the Admin Roles page, click Create Role. The Create Admin Role page appears.

Enter a unique name for the role.

From the drop-down list, select the User Group that you want to associate with this role. For details, see Associating Admin Groups with Admin Roles.

Optionally, enter a Description.

From the drop-down list, select an existing role that suits your requirements.

Under Permission Settings, the Controller Permissions list shows the list of resources. The resources specific to nZTA are tagged with ZTA and resources specific to ICS are tagged with ICS.

Select the Hide, View only, or Modify permissions for each resource and its attributes. This determines which pages to show and which actions to allow.

Under Permission Settings, the ICS Gateway Configuration list shows the list of ICS Gateway resources.

Click Select Gateways. In the Select Gateways dialog, select one or more Gateways / Clusters from the list and click Apply.

Select the Hide, View only, or Modify permissions for each resource and its attributes. This determines which pages to show and which actions to allow.

Click Create. The newly created custom admin role is displayed in the Admin Roles page.

(Optional) Edit an existing admin role by clicking Actions > Edit. Make any required updates and save the changes.

(Optional) Delete an unused custom admin rule by clicking Actions > Delete. You must confirm the deletion.

New pages added as part of Controller/Gateway updates are visible to Super Admins by default, but hidden for custom admin roles. Super Admins can modify the permissions for the new pages added based on the custom roles created.

Workflow: Creating a Local Authentication Policy

This process involves creating a local authentication method and defining within it all user credentials necessary to identify and authenticate your end-users. Before you begin, make sure you have all user details (name and password) ready.

NSA includes built-in default authentication policies, each of which references a built-in local authentication method.

To configure a new local authentication method:

Log into the NSA as a Tenant Admin

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Management > Authentication Servers.

The Authentication Servers page appears. This page lists all existing admin authentication methods. For example:

Click Create Authentication Server.

A form appears that enables you to define the authentication method.

At any point during this process, you can reset the form data by clicking Reset. You can also view existing authentication methods in a pop-up dialog by clicking View Auth Methods.

Under Choose name and type:

Enter an Authentication Server Name.

Select the Authorization Type of Local.

Configure the password options. This is applicable to default Admin Auth and default User Auth.

Settings	Guidelines
Minimum length	Specify a number of characters. The valid range is 6-128. 6 is the default.
Maximum length	Specify a number of characters. The valid range is 6-128. 128 is the default. The maximum length cannot be less than the minimum length.
Minimum digits	Specify the number of digits required in a password. Do not require more digits than the value of the maximum length option.
Minimum letters	Specify the number of letters required in a password. Do not require more letters than the value of the maximum length option. If you enable the previous option, the combined total of the two options cannot exceed that of the value specified in the maximum length option.
Uppercase and lowercase required	Select this option if you want all passwords to contain a mixture of uppercase and lowercase letters. Require passwords to contain at least two letters if you also require a mix of uppercase and lowercase letters.

Special Characters	Select this option if you want password should contain any special characters
Different from current password	Select this option if the password must not be same as the current password.
Different from username	Select this option if the password must not be same as the username.
Different from previous password	Select this option and then select a number from the drop-down if a new password must not be same as the previous number of passwords.
Force password change	Select this option to specify the number of days after which a password expires. The default is 180 days.
Allow users to change passwords	Select this option if you want users to be able to change their passwords. In addition to selecting local authentication password management options, you must select the Enable Password Management option for the associated realm authentication policy.
Prompt users to change password	Select this option to specify when to prompt the user to change passwords.

Click Create User and enter the following settings:

Enter User Name, Full Name, and Email for the user.

Enter 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 Add To Users List.

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.

(Optional) To edit a listed authentication method, select its check box and select Actions drop-down and then click Edit. Make any required updates and confirm.

(Optional) To delete one (or more) unused authentication methods, select the check box for each, select Actions drop-down and click Delete. You must confirm the deletion.

After you have created your local authentication method, create or update your authentication policy with the new authentication method. In most cases, you need a minimum of one policy:

admin sign-in

NSA allows for the definition of custom policies to facilitate separate authentication endpoints for specific groups of users. To learn more, see Viewing Admin Authentication Policies.

Repeat the following steps for each policy, starting with enrollment:

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Management > Admin Policies. The Admin Policies page appears. This page lists all existing user authentication policies.

To learn more about the policies on this page, see Viewing Admin Authentication Policies. From this page, either create a new custom policy or edit an existing policy.

To add a new custom policy, click Create Admin Policy. The Create Admin Policies form appears.

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 admin 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 NSA. Example value: "*/login/admin/".

(Optional) Enter a description for the authentication policy.

Select a User Type based on the intended authentication activity for this policy. Choose from:

Administrators: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the NSA only.

Under Auth Servers, click Primary Auth Server, and select the required authentication method for the policy from the drop-down list.

Click Secondary Auth Server, and select the required authentication method for the policy from the drop-down list.

Click Create Admin Policy to create the new policy. The new policy is added to the list of authentication policies. The new policy is added to the list of authentication policies.

If you instead elect to update an existing custom or built-in policy:

Select the check box adjacent to the relevant policy, select Actions drop-down and click Edit. The Edit Admin Policies form appears.

For built-in authentication policies, all properties except Primary Auth Server are read-only.

Set the Primary Auth Server to be the new local user authentication method (indicated):

Click Update Admin Policy. The list of authentication policies updates.

Repeat until all required authentication policies are updated.

To ensure that your admin can access the authentication mechanism defined in the policies you configure through this process, make sure your Secure Access Policies are configured with a Admin Group in which these authentication policies are defined.

Workflow: Creating a SAML Authentication Policy With Azure AD and SAML(Custom)

You can use the same work flow for creating SAML (Custom) as well.

NSA supports the use of a cloud-based Active Directory (AD) SAML service to provide authentication for your users.

If you choose to use AD as a SAML Identity Provider (IdP), you do not create any users locally on the NSA. All users will already be present in your remote SAML service.

Configuring NSA to use SAML authentication requires you to create separate SAML apps on the Azure AD platform for the following primary activities:

Admin sign-in

The NSA 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 admin 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.

Log into the NSA as a Tenant Admin.

From the Ivanti Connect Secure menu, click the Administration icon, then select Admin Management > Admin Authentication. The Admin Authentication page appears. This page lists all existing user authentication methods:

Click Create Authentication Server. A form appears that enables you to define the authentication method:

At any point during this process, you can reset the form data by clicking Reset. You can also view existing authentication methods in a pop-up dialog by clicking View Auth Methods.

Under Choose name and type:

Enter an Authentication Server Name. For example: Enrollment or SignIn.

Select the Authorization Type of SAML (Azure AD).

The form expands to show additional settings:

(Optional) Enter a Single Logout URL. For more information.

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.

By default, the ICS 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:

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

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

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 Admin Authentication to create the authentication method. The new SAML user authentication method is added to the list of methods displayed in the Admin 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 Ivanti Connect Secure menu, click the Administration icon, then select Admin Management > Admin Policies. The Admin Policies page appears. This page lists all existing user authentication policies.

To learn more about the policies on this page, see Viewing Admin Authentication Policies. From this page, either create a new custom policy or edit an existing policy.

To add a new custom policy, click Create Admin Policy. The Create Admin Policies form appears.

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.

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 admin 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 NSA. Example value: "*/login/adminlogin/".

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 Viewing Admin Authentication Policies.

(Optional) Enter a description for the authentication policy.

Select a User Type based on the intended authentication activity for this policy. Choose from:

Administrators: Select this option to define the authentication endpoint for administrator-level sign-in. This endpoint is used for administrator login to the NSA only.

Under Policy Server Details, click Primary Auth Server, and select the required authentication method for the policy from the drop-down list: Alternatively, select Add New Server and create a new authentication method as per the steps described earlier in this section.

Click Create Admin Policy to create the new policy. The new policy is added to the list of authentication policies.

If you instead select to update an existing custom or built-in policy:

Select the check box adjacent to the relevant policy and click Actions > Edit. The Edit authentication policy form appears.

For built-in authentication policies, all properties except Primary Auth Server are read-only.

Set the Primary Auth Server to be the new SAML user authentication method (indicated):

Click Update Admin Policy. The list of authentication policies updates.

Repeat until all required authentication policies are updated.

At this point, the NSA 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.

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 the Admin Authentication workflow is complete, you can configure the Azure AD platform with the XML configuration of the NSA.

Finally, 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 Admin Group in which these authentication policies are defined.

Checking Tenant Admin Logs

The Tenant Admin Logs page displays logs of all admin activities and events from login to logout such as Register, Delete, Upgrade, Reboot, and Rollback.

It also displays all config authoring use cases except the certificate management. The logs include details of create, update, delete and re-order operations.

The log retention period is 90 days.

To view the Tenant Admin Logs page:

Log in to the Ivanti Neurons for Secure Access Admin portal as a Tenant Admin, and select Ivanti Connect Secure from the Gateway Switcher. See Logging in to Ivanti Neurons for Secure Access.

From the Ivanti Connect Secure menu, select Administration > Tenant Logs.

The Logs page is displayed showing a list of Admin logs, by default, for all the admin activities. To view event logs, select Log Type > Event Logs. All the historical data are shown in event logs.

The table shows the log generated date and time, "Severity", "Message ID" and "Message", and "Source IP" and "Source" Gateway name.

The "Source" field will be empty if the corresponding log is not tied to any specific gateway.

The example screen shows a few admin activities between login and logout. Inline image

Message ID	Action
ADM10005	Restart services
ADM10006	Create configuration
ADM10007	Edit configuration
ADM10008	Delete configuration

For additional list of Message IDs, see Appendix .

Use the time period selectors at the top of the page to set a time period or time range for your log results. For details, see Setting a Log Time Period.

Logs are refreshed automatically by changing the criteria. To manually refresh the log display, click the following icon:

To group the logs based on the fields, use the Group by button and select the field type to view the table information in groups.

To export the displayed log as a CSV or JSON text file, or to set up a new scheduled log export job, click the Export Logs button. To learn more about log export jobs, see Exporting Logs.

To trigger the advanced filter selection, use the following icon. For details, see Filtering the Logs.

To reset the filter, click the following icon:

To change the fields displayed for each log line, click the following icon:

To change the view density, click the following icon:

Synchronizing the Configuration

When admin modifies or updates a device policy or a secure access policy and applies the changes, the synchronization might fail due to any wrong values in the configuration. The Alerts page shows the error log.

Based on the error log information, analyze and fix the configuration. Then use the Sync Now option to initiate the configuration synchronization.

To view the Alerts page, click the Alerts icon and then click See all Alerts:

To synchronize configuration:

From the Ivanti Connect Secure menu, select Administration > Config Status.

The Config Status page shows the status of the config sync, the last updated date and time, and a brief description of config sync.

Click Sync Now.

The Status column displays Success when the configuration synchronization is successful, and the Sync Now button is disabled.

Scanning with External Integrity Checker Tool

You can configure External Integrity Checker tool to scan the system to check for any integrity anomalies. If any anomaly found, information is displayed in the dashboard.

NSA supports external ICT scan on ICS Gateways with version 22.7R2.9 or later, 22.8R2, and 25.1.x.

To trigger Integrity check scan:

From the Ivanti Connect Secure menu, select Administration > Security Center > Integrity Checker Tool.

The Integrity Checker Tool page appears.

The Overview tab shows the following in a table:

list of gateways that support external integrity check

status of the scan process: "Pending", package "Downloading" or integrity check "Failed"/"Completed"

scan type: Shows the last executed scan type - On Demand Scan or Scheduled Scan.

scan start and end times

scan report description

scan history, see Scan History.

if scan is not triggered even once for a gateway, then that row will be empty.

use the search/filter/pagination features to narrow down displayed entries. see Filtering the Logs.

To trigger scan, select the check box next to the gateway and click Scan now. The scan process is initiated immediately.

If the gateway is part of any scheduled scan, the “On demand scan” option is also disabled for that gateway.

To schedule scan, select the check box next to the gateway and click Schedule Scan.

1. From the Gateways list, select the gateway.

2. Select the Start Date.

3. From the Recur every drop-down list, select one of the options:

- Day: Click the time icon and select the start time.

- Week: Select the days of the week. Click the time icon and select the start time.

- Month: Select one of the options:

- On date: Specify a date in the month. Click the time icon and select the start time. For example, on 10th of every month at 5:15AM.

If On date is selected as 31st, then the scan will be triggered only for months that have 31 days in it

- On First/Second/Third/Fourth/Last week of month on Sunday/Monday/Tuesday/Wednesday/Thursday/Saturday.

Time is represented in Timezone set in the Timezone settings.

4. If you want to end the recurring schedule on a specific date, select End by date. Else, select the No end date option.

The Integrity Checker Tool's scan results sometimes display "Detected New Files" as 2; this is expected behavior. For more information, see Interpreting the External Integrity Scan Output.

Scan History

The scan history shows the results of the last three scans run on a gateway.

To view scan history:

In the ICT Overview page, click the history icon corresponding to the gateway.

The History window appears with the following details:

status of the scan

scan description

scan type: On Demand Scan or Scheduled Scan.

For scan with Completed status, gateway generates snapshot. Click the Snapshot download icon to download snapshot (applicable to Gateway version 22.7R2.10 or higher).

Email alerts and notifications are available for External ICT failures.

Managing Scheduled Scans

You can stop, restart, or delete a scheduled scan.

In the ICT Scheduled scan page:

To stop a pending scan, select the check box beside the scan name and then click Stop Scan.

To start a stopped scan, select the check box beside the scan name and then click Restart Scan.

To delete a pending scan, select the check box beside the scan name and then click Delete Scan.

Scheduled Scan page does not show the Stopped / Restarted information.

Configuring Role Based Access for Integrity Checker Tool

You can choose Hide, View only, or Modify permissions for Integrity Tool.

To set the permission:

Select Administration > Admin Roles.

Select the check box corresponding to the role name.

Click Actions > Edit.

The Edit Role window appears.

Select Controller Permissions > Administration, and choose the necessary permission for Integrity Checker Tool.

Limitation

Below listed are the limitation in this release:

Overview page does not show latest scan type until the scan is executed. The last scan execution details is shown during this time.

If the gateway is part of any scheduled scan, “On demand scan” option is also disabled for that gateway.

In Scheduled scan page, Schedule status, i.e., Stopped / Restarted, information is not shown.

Scanning with Indicator of Compromise

The Indicator of Compromise (IoC) feature is a licensed NSA capability that scans ICS gateways for runtime anomalies and threats. It reports gateway health status to the ICT service and triggers admin alerts. Administrators can also initiate on-demand scans for individual gateways using the IoC sets configured in NSA.

Creating IoC Set

To create IoC set:

From the Ivanti Connect Secure menu, select Administration > Security Center > Discover and Manage Threats > Search with IoCs.

The IoC Sets page is displayed.

Click Create IoC to create the IoC set. An IoC set can have a maximum of nine indicators with five different values. Enter the indicators and values, and then click Apply. You can create a maximum of 10 IoC sets.

The IoC set template is listed in the IoC sets page.

Triggering Gateway Scan

To trigger the scan on one or more gateways:

In the IoC sets page, select Gateway scans tab.

From the drop-down list, select the IoC set template.

Select one or more active gateways and click Trigger scan.

Once the scan is complete, the Scan Status column shows Completed and report is generated. Click Download report to view the scan report.

Notifications related to the admin events will be listed in the Alerts page.