# Sending Kiteworks Events to Microsoft Sentinel via the Logs Ingestion API

> Stream Kiteworks PubSub events into Microsoft Sentinel using Azure's Logs Ingestion API and Data Collection Rules — deploy the ARM template, wire up the webhook, and migrate off the deprecated HTTP Data Collector API.

Integrations

# Sending Kiteworks Events to Microsoft Sentinel via the Logs Ingestion API

Kiteworks PubSub can stream audit-log events into Microsoft Sentinel for centralized security monitoring. This guide documents the **current, supported way** to do that: via Azure's **Logs Ingestion API** with **Data Collection Rules (DCR)**.

This replaces an older approach that used the Azure Log Analytics **HTTP Data Collector API** (the "Send Data" connector inside a Logic App). Microsoft is deprecating that API, along with its Workspace-Key based authentication. If you already have the old Logic App integration running, you don't need to rip it out immediately — this guide includes a section on [migrating and safely decommissioning](#migrating) the old resources once the new setup is verified.

In this guide

1. [What this integration does](#what-it-does) — old vs. new architecture
2. [Why this matters](#why-integrate) — future-proofing, stronger auth, schema flexibility
3. [Architecture](#architecture) — the full event pipeline
4. [Prerequisites](#prerequisites) — Azure and Kiteworks access requirements
5. [Known limitations](#limitations) — retries, manual re-runs, no built-in filtering
6. [Step 1: Deploy the ARM template](#step-1) — provisions the whole Azure-side pipeline
7. [Step 2: Verify the deployment](#step-2) — identity and role assignment
8. [Step 3: Set up a webhook](#step-3) — in your Kiteworks tenant
9. [Step 4: Test that logs are arriving](#step-4) — confirm ingestion end to end
10. [Step 5: Add inbound IP restrictions](#step-5) — recommended hardening
11. [Migrating from the old setup](#migrating) — decommissioning the HTTP Data Collector API
12. [Troubleshooting](#troubleshooting) — common issues and fixes
13. [Summary](#summary) — the five pieces, at a glance

## What this integration does

The Logs Ingestion API is the modern replacement for the deprecated HTTP Data Collector API, and it changes several things under the hood:

| Aspect | Old (deprecated) | New |
|---|---|---|
| Connector | `azureloganalyticsdatacollector` ("Send Data") | Direct HTTP action |
| API | HTTP Data Collector API | Logs Ingestion API |
| Authentication | Workspace ID + Key | Managed Identity |
| Destination config | Workspace ID in connector | Data Collection Endpoint (DCE) + DCR + Stream |
| Table type | MMA-based | DCR-based |

## Why this matters / benefits

- **Future-proofing.** The old Data Collector API is being deprecated by Microsoft; this is the path that will keep working.
- **Stronger authentication.** Managed Identity replaces a static Workspace Key, removing a long-lived secret from the equation on the Azure side.
- **Schema flexibility.** DCR-based custom tables support a transformation step, so the raw nested Kiteworks JSON payload can be flattened into proper columns rather than landing in a handful of generic fields.
- **One-shot infrastructure setup.** An ARM template provisions the custom table, DCE, DCR, Logic App, and the necessary role assignment in a single deployment, reducing manual configuration drift.
- **Centralized security visibility.** As with the other SIEM integrations, the end goal is the same: Kiteworks content and admin events become queryable, correlatable data inside Sentinel.

## Architecture

- **Kiteworks PubSub** sends events to the **Logic App**'s webhook.
- The Logic App authenticates using its **Managed Identity** and posts to the **Logs Ingestion API**.
- The **DCE + DCR** transforms the raw JSON and routes it into the **custom table**.
- **Microsoft Sentinel** queries that custom table in the Log Analytics Workspace.

1. Kiteworks PubSub sends events to the Logic App's webhook.
2. The Logic App authenticates using its Managed Identity and posts to the Logs Ingestion API.
3. The Data Collection Rule (DCR) transforms the raw JSON and routes it into the custom table.
4. Microsoft Sentinel queries that custom table in the Log Analytics Workspace.

> **Cost note:** the Logic App is a metered Azure feature, billed per event processed. See Microsoft's [Logic Apps consumption pricing](https://azure.microsoft.com/en-us/pricing/details/logic-apps/) for current rates.

## Prerequisites

- A Log Analytics Workspace with Microsoft Sentinel enabled.
- A Resource Group for the Logic App — **must be the same Resource Group** as the Log Analytics Workspace.
- Global Administrator rights in the Azure tenant (or equivalent rights sufficient to create Logic Apps and assign roles).
- A Kiteworks deployment with PubSub enabled.
- System Administrator rights in the Kiteworks tenant.
- A Windows (cloud) machine to run a PowerShell script.
- A Kiteworks API license, to create the custom Kiteworks application used for the subscription.

## Known limitations

- Kiteworks-side auth uses OAuth, but the Azure side authenticates the inbound webhook call via a static SAS token embedded in the Logic App URL. It's recommended to add inbound IP restrictions in Azure as extra protection (see [Step 5](#step-5) below).
- PubSub retries a failed delivery up to 5 times. If the Logic App is unavailable for all 5 attempts, that event is lost — it will not be ingested.
- If the Logic App receives an event but fails to forward it into the Log Analytics Workspace, the failure shows up in the Logic App's run history. Failed runs must be **re-executed manually within 90 days** or they're gone.
- There's no built-in event filtering yet. If you need to filter which events get processed, that has to be added into the PowerShell CLI script yourself.

## New installation — first-time setup

### Step 1: Deploy the ARM template

The ARM template provisions everything in one deployment:

- The custom table in the Log Analytics Workspace (`KwPubSub_CL`)
- A Data Collection Endpoint (DCE)
- A Data Collection Rule (DCR) with the JSON transformation logic
- A Logic App with Managed Identity enabled and a webhook trigger
- The **Monitoring Metrics Publisher** role assignment on the DCR for the Logic App

**To deploy via the Azure Portal:**

1. Navigate to your Resource Group.
2. Click **Deployments → + Custom deployment → Build your own template in the editor**.
3. Paste the ARM template JSON and click **Save**.
4. Fill in the parameters: `workspaceResourceId` and `workspaceName`.
5. Click **Review + Create**, then **Create**.

### Step 2: Verify the deployment

1. Navigate to the Logic App in the Azure Portal.
2. Confirm the **Identity** section shows a **System Assigned** identity set to **On**.
3. Navigate to the Data Collection Rule and check **Access control (IAM)** — confirm the Logic App has the **Monitoring Metrics Publisher** role.
4. Copy the **Workflow URL** from the Logic App's overview page (or take it from the deployment output). You'll need this in [Step 3](#step-3).

### Step 3: Set up a webhook in your Kiteworks tenant

1. Navigate to `[your-kiteworks-url]/cfadmin`.
2. Log in as **System Administrator**.
3. Confirm the PubSub role is deployed.
4. Navigate to **Event Subscriptions**.
5. Add the **Workflow URL** (copied in Step 2) as the **Webhook URL**.
6. Select the event categories you want forwarded to Sentinel.

### Step 4: Test that logs are arriving

1. Trigger an event in Kiteworks, and allow some time to pass for Log Analytics ingestion, which occurs with a delay.
2. In the Azure Portal, navigate to your **Log Analytics Workspace**.
3. Open the custom table `KwPubSub_CL` and check whether the event appears.

### Step 5 (recommended): Add inbound IP restrictions

1. Find PubSub's outgoing IP from the `X-Forwarded-For` header in one of the Logic App's run logs. You can use a tool like [whois.domaintools.com](https://whois.domaintools.com/) to resolve the CIDR range.
2. In the Logic App, go to **Settings → Networking** and add that CIDR under IP restrictions.
3. Re-test to confirm logs still make it into Sentinel after locking this down.

## Migrating from the old HTTP Data Collector API setup

If you already have the previous "Send Data" Logic App integration running:

1. First, verify the new Logs Ingestion API setup is working end to end (Steps 1–4 above).
2. Update the PubSub subscription to point at the **new** webhook URL, then delete the **old** Logic App.
3. Delete the old `azureloganalyticsdatacollector` API connection resource.

> Don't delete the old resources until you've confirmed the new pipeline is delivering events — this avoids a gap in ingestion.

## Troubleshooting

### Logic App returns 403 Forbidden

The Managed Identity is missing the correct role. Confirm the Logic App's system-assigned identity has **Monitoring Metrics Publisher** specifically on the **Data Collection Rule**, not just on the Resource Group.

### Logic App returns 204 but no logs show up

This is usually just ingestion lag; wait several minutes before assuming something's wrong.

### Only a few standard fields show up in the table

Check that your table schema and DCR transformation cover all the fields you expect. The ARM template's transformation KQL is what flattens the nested `payload` object into individual columns; if a field is missing, it likely needs to be added there.

### Redirect URL mismatch during PubSub subscription setup

If the PowerShell script's browser flow shows a redirect URL error, verify the redirect URL configured on the Kiteworks custom application matches exactly.

### Having issues with your PubSub configuration

See [PubSub Quick Start](../pubsub-quick-start.html) for additional information.

## Summary

| Component | Role |
|---|---|
| **ARM template** | Provisions the full Azure-side pipeline (table, DCE, DCR, Logic App, role assignment) in one deployment |
| **Logic App + Managed Identity** | Receives the PubSub webhook and authenticates to Azure without a static key |
| **Data Collection Rule (DCR)** | Transforms raw JSON into structured columns and routes it to the custom table |
| **Custom table** (`KwPubSub_CL`) | Where Kiteworks events land in the Log Analytics Workspace |
| **Kiteworks Event Subscription** | Defines which event categories get sent, and to which webhook URL |

Once deployed, Kiteworks events flow automatically into Sentinel's custom table with a modern, Managed-Identity-based auth chain — replacing the deprecated Workspace-Key approach and giving you a schema you can extend via the DCR transformation as your monitoring needs grow.

## Also see

[PubSub Quick Start

Register a webhook from the Admin Portal UI and receive your first PubSub event in under 15 minutes.](../pubsub-quick-start.html)

[Splunk Webhooks

Stream Kiteworks events to Splunk Enterprise using the HTTP Event Collector.](kiteworks-events-to-splunk-via-pubsub.html)

[API Reference

Full schema reference for all PubSub webhook endpoints — request bodies, response shapes, and error codes.](../api-reference.html#op/post__webhooks)