Troubleshooting Microsoft Sentinel Event Forwarding

Check Point Portal forwards events to Microsoft Sentinel through the Azure Monitor Logs Ingestion API. This destination uses HTTPS and Microsoft Entra ID application authentication.

It does not require a customer-hosted Syslog receiver, TLS certificates, mTLS certificates, hostname, or port configuration.

For configuration steps, see Microsoft Sentinel.

Notes: TLS and mTLS certificate configuration is not used for this destination. The client secret is write-only in Check Point Portal.

Verify the Configuration

Before troubleshooting, verify that:

• An Event Forwarding contract exists.

• The relevant Check Point Portal services support Event Forwarding.

• The Microsoft Sentinel workspace and Log Analytics workspace exist.

• The target Log Analytics custom table exists.

• The DCR is configured for the Azure Monitor Logs Ingestion API.

• The logs ingestion endpoint is copied from the correct DCR or DCE.

• The Microsoft Entra ID app registration exists and has a valid client secret.

• The app registration has the Monitoring Metrics Publisher role on the DCR.

• The DCR immutable ID and stream name are copied exactly from Microsoft Azure Collection of integrated cloud services that developers and IT professionals use to build, deploy, and manage applications through a global network of data centers managed by Microsoft..

Important - Allow up to 30 minutes for the Azure role assignment to propagate before testing connectivity.

Run a Connectivity Test

Use the Test Connectivity functionality to identify the cause of the issue.

For a New Destination

1. In the Check Point Portal, click > Event Forwarding.

2. Click Create Destination.

3. Complete the New Destination wizard.

4. In the last step of the wizard, clickTest Connectivity.

For an Existing Destination

1. In the Check Point Portal, click > Event Forwarding.

2. Click Manage Destinations.

3. Select the required destination.

4. Open the destination for editing.

5. From the left menu, select Test Connectivity.

6. Click Test Connectivity.

If the test reports:

• Microsoft Entra ID Authentication Failed

• DCR Endpoint Access Failed

• Missing Role Assignment

• Test Event Sent Failed

See the corresponding section below.

Troubleshoot Connectivity Test Failures

If the connectivity test fails, use the error message shown in the test results to identify the cause.

Microsoft Entra ID Authentication Failed

Possible Causes

• Incorrect Azure Tenant ID.

• Incorrect Application (Client) ID.

• Incorrect client secret value.

• Expired client secret.

• The client secret ID was entered instead of the client secret Value.

• The app registration was deleted or disabled.

Resolution

1. In Microsoft Entra ID, open the app registration.

2. Verify the Directory (tenant) ID and Application (client) ID.

3. If the client secret is expired or unknown, create a new client secret.

4. Edit the Event Forwarding destination and enter the new client secret value.

5. Run Test Connectivity again.

DCR Endpoint Access Failed

Possible Causes

• Incorrect logs ingestion endpoint.

• The endpoint was copied from the wrong DCR or DCE.

• The endpoint region does not match the DCR / workspace configuration.

• The DCE or logs ingestion endpoint is private-link-only, or public network access is disabled, so Check Point Portal cannot reach it from outside the customer's private Azure network.

• A firewall, proxy, or network policy blocks HTTPS access to the endpoint.

Resolution

• Verify the endpoint format, for example: https://<endpoint-name>.<region>.ingest.monitor.azure.com.

• Confirm that the endpoint belongs to the DCR or DCE configured for the Sentinel workspace.

• If using a DCE, verify that the DCE is associated with the DCR.

• Verify that Check Point Portal can reach the Logs Ingestion endpoint:

  • Public network access is enabled for the endpoint, or

  • If Azure Network Security Perimeter (NSP) is used, the inbound access rules allow the IP address range associated with your regional Check Point Portal FQDN.

• Run Test Connectivity again.

Missing Role Assignment

Possible Cause

The app registration does not have the required permission to send data through the DCR.

Resolution

1. Open the DCR in Microsoft Azure.

2. Go to Access control (IAM).

3. Assign Monitoring Metrics Publisher to the app registration.

4. Wait up to 30 minutes for the role assignment to propagate.

5. Run Test Connectivity again.

Test Event Submission Failed

Possible Causes

• Incorrect DCR immutable ID.

• Incorrect stream name.

• The stream is not configured in the DCR.

• The DCR data flow does not route the stream to the target table.

• The target table does not exist.

• The DCR transformation does not accept the incoming Check Point test payload.

Resolution

1. In the DCR JSON view, verify the immutableId value.

2. Verify that the stream name configured in Check Point Portal exactly matches the stream name defined in the Data Collection Rule (DCR).

3. Verify that the DCR data flow maps the stream to the expected table.

4. Verify that the target table exists in the Log Analytics workspace.

5. Verify that the DCR transformation accepts the incoming payload.

6. Run Test Connectivity again.

Troubleshoot Data Export Issues

Events Do Not Appear in Microsoft Sentinel

Connectivity test succeeds but events do not appear in Microsoft Sentinel.

Possible Causes

• No new events were generated.

• Events are sent to a different workspace or table.

• The DCR transformation filters the events.

• The destination is inactive.

Resolution

1. Confirm that the relevant Check Point Portal services are configured to send events to the destination.

2. Confirm that new events were generated after the destination was created.

3. In Microsoft Sentinel, query the correct workspace and table.

4. Increase the query time range to account for ingestion latency.

5. Verify that the DCR transformation does not filter out the records.

6. Verify that the destination is active in Check Point Portal.

7. Edit the destination and run Test Connectivity again.

CheckPointEventForwarding_CL | where TimeGenerated > ago(24h) | summarize Count=count() by bin(TimeGenerated, 15m)

Events Appear but Are Not Parsed Correctly

Event Forwarding sends the events to Microsoft Sentinel. Parsing and enrichment in Microsoft Sentinel depend on the customer's table schema, DCR transformation, KQL functions, workbooks, and analytics rules.

Resolution

• Verify the raw event data in the target table.

• Verify the DCR transformation.

• Create or update Microsoft Sentinel parsing logic as needed.

• Contact the Microsoft Sentinel administrator or Microsoft support for Sentinel-side parsing issues.

Note - The TimeGenerated value shown in Log Analytics can differ from the timestamp in the Syslog envelope or the createdAt value in the JSON payload unless the DCR transformation maps TimeGenerated from one of those fields.

Client Secret Expired

Client secret expired after the destination was created.

Resolution

1. In Microsoft Entra ID, create a new client secret for the app registration.

2. In Check Point Portal, edit the Microsoft Sentinel destination.

3. Enter the new client secret value.

4. Update the client secret expiration date.

5. Run Test Connectivity.

6. Save the destination.

Known Limitations

• Event Forwarding exports events as a pass-through service.

• Custom log filtering is not supported.

• Historical export is not supported.

Notes: Microsoft Azure Monitor Logs Ingestion API receives a JSON request body. The Check Point event payload inside the RawData field can be JSON, Syslog, CEF, or LEEF, according to the Event Forwarding format selected in Check Point Portal. If the DCE or Logs Ingestion endpoint is configured for Azure Private Link only, or if public network access is disabled without allowing Check Point Portal IP addresses, direct forwarding from Check Point Portal is not supported.

Collect Information for Check Point Support

If the issue persists, collect the following information:

• Destination name.

• Destination ID, if available.

• Region of the Check Point Portal tenant.

• Microsoft Azure region of the Log Analytics workspace and DCR.

• The Test Connectivity result and request ID.

• Screenshot of the failed Test Connectivity step.

• DCR immutable ID.

• Logs ingestion endpoint.

• Stream name.

• Target table name.

• Approximate time of the test.

• Whether the app registration has Monitoring Metrics Publisher on the DCR.

• Whether the role assignment was created more than 30 minutes before the test.

Do not provide:

• Client secret values.

• Private keys.

• Other sensitive credentials.

References

• Microsoft Learn: Logs Ingestion API in Azure Monitor

• Microsoft Learn: Set up resources required to send data to Azure Monitor Logs using the Logs Ingestion API

• Microsoft Learn: Tutorial - Send data to Azure Monitor Logs with Logs ingestion API in the Azure portale