> ## Documentation Index
> Fetch the complete documentation index at: https://docs.omni.co/llms.txt
> Use this file to discover all available pages before exploring further.

# Using Azure Blob Storage for Omni audit logs

> Track Omni user activity in your instance with structured logs, accessible in an Azure Blob Storage container via a Microsoft Entra application or a SAS token.

<Note>
  Reach out to Omni support to have audit logs enabled for your instance.
</Note>

Audit logs are detailed records of the activity your users are taking in Omni, which can be useful for security and performance analysis. Events included in logs are structured as JSON payloads and sent in batches to your cloud storage a few minutes after they're written.

For Azure, Omni hosts the storage: Omni creates a dedicated storage account and blob container for your instance. You can read your logs using either of two access methods:

|                       | **Microsoft Entra application** (recommended)                         | **SAS token**                              |
| --------------------- | --------------------------------------------------------------------- | ------------------------------------------ |
| Credentials exchanged | None — you authenticate with your own application's credential        | Omni shares a read-only SAS token with you |
| Best for              | Custom tooling, Azure SDKs, anything that can authenticate with Entra | Tools that only support SAS authentication |

## Option 1: Microsoft Entra application (recommended)

Omni grants a Microsoft Entra application that you own read access to your container. You read your logs by authenticating with your own application's credential — there are no storage account keys or SAS tokens to manage, and no credentials are exchanged between you and Omni.

### Requirements

To follow the steps in this guide, you'll need:

* To have audit logs enabled in your Omni instance
* A **multitenant** Microsoft Entra application registered in your tenant, with a client secret or certificate
* Permissions to register an application in your tenant and read its application (client) ID

### Setup

After audit logs are enabled in your instance, complete the following:

<Steps>
  <Step title="Register a multitenant Entra application">
    In the [Microsoft Entra admin center](https://entra.microsoft.com), navigate to **App registrations > New registration**.

    * Set **Supported account types** to **Accounts in any organizational directory (multitenant)**. This is required so Omni can create a service principal for your application in Omni's tenant and grant it access.
    * Under **Certificates & secrets**, add a client secret or certificate. This credential stays in your tenant and is never shared with Omni.
    * Copy the **Application (client) ID**.

    No API permissions are required — you can ignore (or remove) the default `User.Read` permission.
  </Step>

  <Step title="Provide Omni support with your application details">
    Reach out to Omni support with the following:

    * **Application (client) ID** — the UUID of your multitenant application
    * **Tenant ID** — your Entra tenant ID (the application's home tenant)
  </Step>

  <Step title="Complete setup with Omni support">
    Omni provisions a service principal for your application in Omni's tenant, creates your blob container, grants that service principal the `Storage Blob Data Reader` role on it, and starts delivering audit logs.

    Omni support will share:

    * **Omni's tenant ID** — you authenticate against this tenant (see below)
    * The **storage account name** and **container name** for your logs
  </Step>
</Steps>

### Reading the logs

Once configured, audit logs are automatically delivered to your container. Authenticate as your application using the client secret or certificate from Step 1.

<Warning>
  Authenticate against **Omni's tenant ID** (the tenant that hosts the storage), not your own home tenant. Your application's service principal — and the read-access grant — live in Omni's tenant, so a token issued by your own tenant is rejected with a `403` even though access is configured correctly.
</Warning>

With the Azure CLI:

```bash theme={null}
# Sign in as your application, pointed at Omni's tenant.
az login --service-principal \
  --username <APPLICATION_CLIENT_ID> \
  --password <CLIENT_SECRET> \
  --tenant <OMNI_TENANT_ID> \
  --allow-no-subscriptions

# List your audit log blobs. --auth-mode login uses your signed-in identity.
az storage blob list \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --auth-mode login \
  --output table
```

You can also use a tool like [Azure Storage Explorer](https://azure.microsoft.com/products/storage/storage-explorer) or the Azure SDKs — in each case, set the tenant/authority to Omni's tenant ID and the token scope to `https://storage.azure.com/.default`.

### Hardening

Your application only needs to read your audit logs. To keep its footprint minimal:

* **Least privilege is enforced on Omni's side.** Your application's service principal is granted only the `Storage Blob Data Reader` role, scoped to your single audit-log container — no write access and no access to any other container or account.
* **Prefer a certificate over a client secret** for the application credential, and rotate it regularly.
* **Restrict which tenants can use your application.** In the app registration's **Authentication (Preview)** blade, set **Supported account types** to multiple tenants and choose **Allow only certain tenants (Preview)**, then add Omni's tenant ID (and your own). This pins your multitenant application so it can only be used in your tenant and Omni's, rather than any tenant that discovers it. This setting is in preview at the time of writing.

## Option 2: SAS token

If your tooling can't authenticate with Entra, Omni can instead share a read-only [shared access signature (SAS) token](https://learn.microsoft.com/en-us/azure/storage/common/storage-sas-overview) for your dedicated storage account.

### Setup

<Steps>
  <Step title="Request SAS access from Omni support">
    Reach out to Omni support and request SAS-based audit log access.
  </Step>

  <Step title="Receive your access details">
    Omni provisions your dedicated storage account and container, and shares:

    * The **storage account name** and **container name** for your logs
    * The **SAS token** (read and list permissions only, HTTPS only)
  </Step>
</Steps>

### Reading the logs

With the Azure CLI:

```bash theme={null}
az storage blob list \
  --account-name <STORAGE_ACCOUNT_NAME> \
  --container-name <CONTAINER_NAME> \
  --sas-token "<SAS_TOKEN>" \
  --output table
```

### Considerations

* **Treat the token like a password.** Anyone holding it can read your audit logs until it is revoked.
* **Revocation**: if the token is exposed, contact Omni support — Omni rotates the storage account key, which immediately invalidates all outstanding tokens.

## Next steps

* Learn about the [event types](/administration/audit-logs/event-types) supported for audit logs
* Check out your instance's [Analytics section](/administration/analytics)