Using Enterprise Integration to Export Your Logs for External Analysis

31 min

Introduction and Prerequisites

Ivanti Neurons for Zero Trust Access (nZTA) gathers data for events that occur on your nZTA Gateways and from the Controller's Authentication, Authorization and Accounting (AAA) service. These events are categorized and stored in the following log files:

Access Logs

Admin Logs

Event Logs

You can view and obtain these logs at any time through the nZTATenant Admin Portal (for details, see Checking the Logs ).

nZTA enables you to automatically export log data for analysis in an external third-party enterprise analytics or visualizer tool through Enterprise Integration. This enables enhanced visibility into the health and efficiency of the services running in your nZTA deployment, or to facilitate debugging in the event of unexpected service behavior.

Exporting log data to an external analytics endpoint

To receive the log data exported from nZTA, your analytics endpoint should employ a syslog service that supports ingestion of data in JSON or WELF format. Syslog is a protocol defined through RFC 5424, and nZTA supports exporting log data to any Security Information and Event Management (SIEM) system that can accept and parse syslog messages. Supported configurations are:

A publicly-reachable syslog server for your Controller. This requires you to configure nZTA with the hostname or IP address and port on which the analytics service is listening, and with the client certificate to use to authenticate nZTA to the syslog service.

An on-prem syslog server for your nZTA Gateway(s). This requires you to configure nZTA with the hostname or IP address and port on which the analytics service is listening, and with the required protocol for the syslog service.

To use this facility, you must:

Obtain and import a trusted Server Certificate Authority (CA) certificate suitable for the analytics service, see Importing a Trusted Server CA Certificate.

Obtain and import a client authentication certificate for nZTA, see Adding a Client Certificate to the Controller.

A client certificate is not required for an on-prem syslog server.

Configure the Controller with the details of either:

Your publicly-reachable syslog server, see Adding a Public Syslog Server to the Controller.

Your on-prem Gateway syslog server, see Adding an On-Prem Syslog Server for nZTA Gateways.

Importing a Trusted Server CA Certificate

To export your logs to an analytics service, you first need to add a certificate for a Trusted Server Certificate Authority (Server CA).

Make sure you have a suitable certificate file, in PEM (Base64 ASCII encoded) format, stored on your local workstation before starting this procedure.

nSA supports certificate files in PEM format only. Other formats, such as PFX, are not currently supported.

To import a certificate for a trusted server CA:

Log into the Controller as a Tenant Admin, see Logging in as a Tenant Administrator.

From the nSA menu, click the Administration icon, then select Enterprise Integration > Trusted Server CA. The Trusted Server CAs page appears.

Viewing Trusted Server CA certificates

To import a Server CA certificate, click Import. The Import Server CA page appears.

Importing a Trusted Server CA certificate

Click Certificate File and use the subsequent dialog to locate the certificate file from your local workstation file system.

To import the selected certificate, click Import Certificate. The Trusted Server CAs page appears showing the successfully imported certificate.

(Optional) To view the details stored in a certificate, select the certificate checkbox and click Details.

(Optional) To delete a certificate, select the certificate checkbox and click Delete.

You can import more than one trusted server CA certificate.

After you have imported your trusted server CA certificate to the Controller, proceed to add your client certificate (see Adding a Client Certificate to the Controller).

Adding a Client Certificate to the Controller

Before you can export your logs to an analytics service, you must add a client certificate to verify the identity of the Controller to the external service.

A client certificate is not required for an on-prem syslog server.

Make sure you have a suitable client certificate file, in PEM (Base64 ASCII encoded) format, stored on your local workstation before starting this procedure.

nSA supports certificate files in PEM format only. Other formats, such as PFX, are not currently supported.

To import a client certificate:

Log into the Controller as a Tenant Admin, see Logging in as a Tenant Administrator.

From the nSA menu, click the Administration icon, then select Enterprise Integration > Client Authentication. The Client Authentication page appears.

Viewing Client Authentication Certificates

To import a client certificate, click Import. The Import Certificate page appears.

Importing a Client certificate

Click Certificate Type and select one of the following options:

Client Certificate with embedded private key: Use this option if you are importing a certificate file with an embedded private key.

Client Certificate with separate private key: Use this option if you are importing a certificate file with a separate private key file.

nSA updates the page to show the relevant import fields based on your selected option.

Click Certificate File and use the subsequent dialog to locate the certificate file from your local workstation file system.

(Optional) If you selected to use a separate private key, click Private Key File and use the subsequent dialog to locate the private key file from your local workstation file system.

(Optional) For Password Key, enter your private key passphrase.

To import the selected client certificate, click Import Certificate. The Client Authentication page appears showing the successfully imported client certificate.

(Optional) To view the details stored in a certificate, select the certificate checkbox and click Details.

(Optional) To delete a certificate, select the certificate checkbox and click Delete.

You can import more than one client certificate.

After you have imported your Trusted Server CA certificate and Client certificate to the Controller, proceed to add the details of your external analytics service (see Adding a Public Syslog Server to the Controller).

Adding a Public Syslog Server to the Controller

Before you configure a publicly-reachable Syslog server on the Controller, ensure that:

Your Syslog server is publicly-reachable, and that you know the hostname or IP address and port of the service.

You have already added suitable Server CA and Client certificates.

Server CA Selection

To optimize Syslog server connectivity and performance, the Syslog Server configuration interface now includes a new drop-down enabling users to explicitly select the Target Server CA (Certificate Authority) when setting up secure connections. This enhancement complements the existing client certificate option and addresses latency issues during SSL handshakes.

Key Improvements

Targeted Server CA Selection:

Administrators can now specify which Server CA to use when configuring Syslog servers. Previously, if no Server CA was selected, the system sequentially tested all trusted CAs in the tenant during connection establishment, which increased connection times. This results in a better performance and a better user experience.

Reduced Latency and Streamlined Handshakes:

Enhanced the syslog forwarding mechanism to enable real-time log delivery by directly consuming gateway log events.

Improved Security and Accuracy:

By ensuring the correct Server CA is always used, this enhancement minimizes the risk of mismatched certificates and strengthens secure logging communications.

Enhanced User Experience:

The refined UI makes Syslog server setup more intuitive and efficient, speeding up configuration and accelerating message delivery.

Administrators are encouraged to specify the relevant Server CA when adding or editing Syslog server configurations to gain the benefits of this enhancement.

To configure a Syslog server in the Controller:

Log into the Controller as a Tenant Admin, see Logging in as a Tenant Administrator.

From the nSA menu, click the Administration icon, then select Enterprise Integration > Syslog Servers. The Enterprise Integrations page appears.

Viewing Enterprise Integration Syslog Servers

Click Add. The Add New Configuration page appears, on the Configuration tab.

For Type, select Syslog via Controller.

Add a new Syslog Server configuration

Enter data for the following fields:

Server Name: An identifying name for this Syslog server configuration.

Facility: The syslog facility level nSA should use while exporting log data.

Hostname or IP: The hostname or IP address of the Syslog server. This must match the value contained in the Subject Alternative Name specified in the Server CA certificate applicable to this configuration.

Port: The port on which the Syslog server is listening.

Protocol: This field is read-only.nZTA supports only the TLS protocol in this instance.

Client Certificate: The client certificate you want to use with this Syslog server.

Trusted Server CAs: Select Trusted Server CA to use from the drop-down list.

Specify or create a Custom Filter to select the log data sent to the Syslog server. Choose from:

Use either of the predefined "JSON" or "WELF" filters. These do not place restrictions on the log data and forward all logs to the external syslog server, using the respective data format.

Create your own filter, based on log parameter rules you define yourself, see Setting a Custom Syslog Filter.

The predefined JSON and WELF filters are fixed and cannot be updated or deleted.

Click Next to select the required log files. The Selected Logs tab appears.

Select the logs to be exported

From the list of Available Logs, select the check box adjacent to the desired log and click the arrow to move it to the the Selected Logs list. Repeat this step for each log you want to include. Use the reverse process to remove included logs.

To create a Syslog server configuration with the current settings, click Save Changes.

Optionally:

To edit an existing Syslog server configuration, select the check box adjacent to the configuration entry and click Edit.

To duplicate an existing Syslog server configuration, select the check box adjacent to the configuration entry and click Duplicate. This creates a complete copy of the chosen configuration using the same server name appended with "-copy".

To delete an existing Syslog server configuration, select the check box adjacent to the configuration entry and click Delete.

Adding an On-Prem Syslog Server for nZTA Gateways

Before you configure an on-prem syslog server for nZTA Gateways to Controller, make sure you have added a suitable Server CA certificate. To learn more, see Importing a Trusted Server CA Certificate.

Ensure that know the hostname or IP address and port of the service.

To configure an on-prem Syslog server for nZTA Gateways in the Controller:

Log into the Controller as a Tenant Admin, see Logging in as a Tenant Administrator.

From the nSA menu, click the Administration icon, then select Enterprise Integration > Syslog Servers. The Enterprise Integrations page appears.

Viewing Enterprise Integration Syslog Servers

Click Add. The Add New Configuration page appears, on the Configuration tab.

For Type, select Syslog from Gateways.

Add a new Syslog Server configuration

Enter data for the following fields:

Server Name: An identifying name for this Syslog server configuration.

Facility: The syslog facility level nSA should use while exporting log data.

Hostname or IP: The hostname or IP address of the Syslog server. This must match the value contained in the Subject Alternative Name specified in the Server CA certificate applicable to this configuration.

Port: The port on which the Syslog server is listening.

Protocol: the required protocol for communicating with your on-prem Syslog server. Both TCP and UDP are supported.

Client Certificate: This field is unavailable.

Specify or create a Custom Filter to select the log data sent to the Syslog server. Choose from:

Use either of the predefined "JSON" or "WELF" filters. These do not place restrictions on the log data and forward all logs to the external Syslog server, using the respective data format.

Create your own filter, based on log parameter rules you define yourself, see Setting a Custom Syslog Filter.

The predefined JSON and WELF filters are fixed and cannot be updated or deleted.

Click Next to select the required gateways. The Selected Gateways tab appears.

Select the gateways

From the list of Available Gateways, select the check box adjacent to the desired Gateway and click the arrow to move it to the the Selected Logs list. Repeat this step for each Gateway you want to include. Use the reverse process to remove included nZTA Gateways.

Click Next to select the required log files. The Selected Logs tab appears.

Select the logs to be exported

From the list of Available Logs, select the check box adjacent to the desired log and click the arrow to move it to the the Selected Logs list. Repeat this step for each log you want to include. Use the reverse process to remove included logs.

To create a Syslog server configuration with the current settings, click Save Changes.

Optionally:

To edit an existing Syslog server configuration, select the check box adjacent to the configuration entry and click Edit.

To duplicate an existing Syslog server configuration, select the check box adjacent to the configuration entry and click Duplicate. This creates a complete copy of the chosen configuration using the same server name appended with "-copy".

To delete an existing Syslog server configuration, select the check box adjacent to the configuration entry and click Delete.

Setting a Custom Syslog Filter

nSA enables you to create a custom filter that builds a query to specify the data items exported to your Syslog server. You can specify criteria based on matching log data fields, date selection, and log output format.

This procedure assumes you are in the process of creating or editing a Syslog server configuration. To learn more, see Adding a Public Syslog Server to the Controller.

To add a custom syslog filter:

From the Add New Configuration page, locate the Custom Filters section and click Add. The Custom Filter dialog appears.

Setting a custom syslog filter

Use Select existing or create new filter to either:

Create a new filter from scratch.

Select an existing filter as a template. This option pre-populates the Expression and Format String fields with values used in the selected filter, which you can then use to create your new filter.

Enter a Filter Name.

Select a Start Date and End Date for the log data to be included. Use the default Earliest and Latest values to include all data, or select custom start and end dates, or a combination.

nZTA stores log data for the previous 30 days.

(Optional) To use this filter as the default for your Syslog Server configurations, select Default Filter.

(Optional) Select from the list of available log data Variables, select an Operator, and then click Add Variable to add a filter based on the chosen value. nSA populates the Expression field with an expression matching your selection. An example value is added to the right of the operator, but this can be freely edited to your required value.

Building a custom syslog filter expression based on the log fields: message ID, local IP address, and protocol.

Hover your pointer over the (i) icon to the right of each variable to view a tooltip showing example usage.

(Optional) Repeat the previous step as required for each log data variable you want to include in the syslog filter.

Select an output Format for the log line. Choose from JSON or WELF. The resultant formatted string is shown in the box provided.

To save your filter settings, click Save Changes.\ The Add New Configuration screen appears, showing your new filter as selected. Continue to create your Syslog server configuration.

Enable BYOD Using Machine Certificate based Validation

This feature describes Zero Trust Access (ZTA) capability that enables Bring Your Own Device (BYOD) access using machine certificate–based device validation. It covers the feature overview, supported platforms, configuration workflow in the ZTA Admin Console, enforcement behavior, and troubleshooting guidance for tenant administrators.

Feature Overview

Machine Certificate based Device Policy: This capability lets administrators enforce device trust by validating a machine-level certificate installed on an endpoint. When enabled, only devices presenting a valid, trusted machine certificate can register, authenticate, and access protected applications through ZTA.

Device trust is evaluated via a Machine Certificate device policy rule.

The rule uses CAs uploaded as Trusted Client CAs in the tenant.

Evaluation can be applied at device registration (enrollment), user login, and application access.

Organizations that permit BYOD need controls beyond user identity to ensure devices meet trust requirements.

With machine certificate–based validation:

ZTA verifies device trust in addition to user identity.

A machine certificate issued by an approved CA serves as device authorization proof.

Devices without a valid machine certificate are blocked at configured enforcement points.

Benefits

Administrators can:

allow or block device registration based on the presence and trust of a machine certificate.

allow or block user login based on machine certificate validation.

control application access through device policies that check machine certificates.

Key Benefits

Strong device-level trust for BYOD and non-managed endpoints

Reduced risk of unauthorized devices accessing protected resources

Consistent enforcement at registration, authentication, and application access

Clear separation of Server CA vs. Client CA usage for trust chains

Trusted Client CA usage: When uploading certificates, administrators can designate usage as Server CA or Client CA. Only Client CAs are used for machine certificate validation in device policies.

Multi-stage enforcement: The same device policy can be evaluated at device registration, user login, and application access.

Supported Platforms

Windows

macOS

- Validation requires the machine certificate be present in the device’s machine store (Windows) or system keychain (macOS). - Current Ivanti Secure Access Client for Windows and macOS supports this capability; no separate client upgrade is typically required for ZTA use.

Setup and Configuration

Prepare Trusted Client CAs

Create a Machine Certificate Device Policy Rule

Prepare Trusted Client CAs

In the ZTA Admin Console, go to the Certificates area for the tenant.

Upload the issuing CA chain and set Usage to Client CA.

Verify the CA appears under Trusted Client CAs. Only CAs marked as Client CA are available for machine certificate rules.

Create a Machine Certificate Device Policy Rule

Navigate to Tenant Administration > Device Policies and create or edit a device policy.

Add a new rule and choose the Machine Certificate rule type.

Select the appropriate Trusted Client CA that issued the machine certificate.

(Optional) Add certificate attribute checks (for example, subject or issuer contains specific values) to further scope acceptable certificates.

Save the rule and policy.

Apply the Device Policy at Enforcement Points

Device registration (enrollment): Attach/apply the device policy so registration requires a valid machine certificate.

User login (authentication): Apply the policy so login requires machine certificate validation.

Application access using Secure Access Proxy (SAP): Apply the policy to resource access policies so app access requires machine certificate validation.

Key Configuration Considerations

Rule Type: Machine Certificate appears alongside other device rule types in Device Policies.

CA Selection: Only CAs uploaded as Trusted Client CA are selectable.

Certificate Scope: The device must present a valid machine certificate that chains to the selected Trusted Client CA.

Certificate Store: The certificate must be installed in the machine store (Windows Local Computer store) or macOS System keychain, not the user store.

Optional Attributes: Subject or issuer matching can be used to constrain acceptable certificates to specific patterns.

Backward Compatibility

Existing certificate management and device policies remain unchanged until you add or edit policies to include Machine Certificate rules.

Enforcement Points

Machine certificate validation can be enforced at:

Device registration (enrollment)

User authentication (login)

Application access (through SAP)

If the device fails machine certificate validation at any stage where the rule is applied, access is denied according to the configured policy.

Troubleshooting and Debugging Logs and Diagnostics

Client-side: Enable and review client debug logs for device registration outcomes and certificate discovery issues.

Console-side: Use the ZTA Admin Console logs/events to review device policy evaluations for login and application access.

Common Issues and Recommendations

Certificate location:

Windows: Verify the certificate is in Local Computer > Personal > Certificates (not Current User).

macOS: Verify the certificate is in the System keychain (not the login keychain).

CA trust:

Ensure the device’s machine certificate chains to a CA uploaded as Trusted Client CA in the tenant.

Confirm you selected the correct Client CA in the rule configuration.

Certificate validity:

Check certificate validity dates and that the certificate isn’t revoked.

If used by your PKI, ensure Extended Key Usage includes Client Authentication.

Attribute matching:

If you set subject/issuer filters, confirm the device certificate’s fields match those values.

Machine certificate-based device validation strengthens ZTA by adding device trust to BYOD workflows. By requiring a valid machine certificate at device registration, user login, and application access, administrators ensure that only authorized, trusted devices can connect to protected resources without disrupting existing certificate management or device policies.