Connect Qevlar to Microsoft Sentinel to investigate Sentinel incidents and query Log Analytics workspace data. This page lists the Azure permissions Qevlar requires and how to grant them.
Overview
Qevlar authenticates as an Entra ID (Azure AD) app registration using the OAuth 2.0 client credentials flow — no user account or interactive sign-in. Authorization is granted through Azure RBAC role assignments on the Log Analytics workspace.
Qevlar calls two Azure APIs, each with its own access token:
| API | Purpose | Token audience |
|---|---|---|
| Log Analytics query API | Run read-only KQL queries against the workspace | https://api.loganalytics.io |
| Azure Resource Manager | Read Sentinel incidents, alerts, and entities; optionally write comments and tags | https://management.azure.com |
Both tokens are issued by https://login.microsoftonline.com/{tenantId}/oauth2/token using the same client ID and secret.
Connection details
Enter these values when configuring the connector in Qevlar:
| Field | Where to find it | Required |
|---|---|---|
| Tenant ID | Entra ID → Overview | Yes |
| Client ID | App registration → Overview | Yes |
| Client Secret | App registration → Certificates & secrets | Yes |
| Workspace ID | Log Analytics workspace → Overview (workspace GUID) | Yes |
| Subscription ID | Subscription containing the workspace | Incident features |
| Resource Group | Resource group containing the workspace | Incident features |
| Workspace Name | Log Analytics workspace name | Incident features |
The last three fields are required only for Sentinel incident features — reading an incident's alerts and entities, and writing comments and tags. Without them, Qevlar can still run KQL queries against the workspace.
Required permissions
Who can set this up: this connector requires an Azure administrator — rights to create an app registration in Entra ID (Application Administrator, or Global Administrator if app registration is restricted in your tenant), plus Owner or User Access Administrator on the Log Analytics workspace or its resource group to assign the roles below.
Assign Azure built-in roles to the app registration's service principal, scoped to the Log Analytics workspace or its resource group — not the subscription. Both roles below are read-only, and Qevlar only reads data related to the alerts it investigates. These are the narrowest built-in roles that grant the access Qevlar needs.
Read-only (minimum) — everything Qevlar needs to investigate:
| Role | Grants | Why Qevlar needs it |
|---|---|---|
| Log Analytics Reader | Read-only KQL queries via the Log Analytics query API | Pull the specific log records behind an alert — the process, sign-in, network, or email events for the entities involved — to confirm whether the activity is malicious. Without it, Qevlar cannot verify the alert against the underlying telemetry. |
| Microsoft Sentinel Reader | Read incidents, incident alerts, and incident entities | Read the triggering incident and its alerts and entities — the users, hosts, IPs, and files — so Qevlar knows what to investigate. |
For tighter least-privilege control, Log Analytics supports table-level RBAC: instead of Log Analytics Reader, you can assign a custom role that grants read access only to the specific tables Qevlar queries. The exact tables depend on which scanners you enable.
Write-back (optional) — only if you want Qevlar to post results back to incidents:
When enabled, Qevlar can write its verdict and a short investigation summary as a comment on the originating Sentinel incident, so analysts see the conclusion directly in Sentinel without switching tools and Sentinel stays the system of record.
| Role | Grants |
|---|---|
| Microsoft Sentinel Responder | Read and update incidents — add comments and tags |
Microsoft Sentinel Responder includes all read permissions of Microsoft Sentinel Reader, so assign Responder instead of Reader when enabling write-back. Microsoft Sentinel Contributor and Owner are not required.
| Goal | Roles to assign |
|---|---|
| Investigations only | Log Analytics Reader + Microsoft Sentinel Reader |
| Investigations + write-back | Log Analytics Reader + Microsoft Sentinel Responder |
Setup
- Create the app registration. Entra ID → App registrations → New registration. Name it (for example
qevlar-sentinel-connector); no redirect URI is needed. Record the Client ID and Tenant ID from the Overview page. - Create a client secret. App registration → Certificates & secrets → New client secret. Copy the secret value immediately — it is shown only once. Note its expiry and plan to rotate it before it lapses. Qevlar also emails your admin users when the secret is nearing expiry or has started failing, so you can rotate it before investigations are affected.
- Collect workspace details. From the Log Analytics workspace Overview, record the Workspace ID (GUID), Workspace Name, Resource Group, and Subscription ID.
- Assign roles. On the workspace or its resource group → Access control (IAM) → Add role assignment. Assign to the app registration's service principal: Log Analytics Reader, plus Microsoft Sentinel Reader (read-only) or Microsoft Sentinel Responder (write-back).
- Configure the connector. In Qevlar, add the Microsoft Sentinel connector and enter the connection details above.
Network access. If you restrict inbound access to your workspace or tenant by IP, allowlist Qevlar's egress IP addresses so it can reach your environment. Qevlar egress IPs: to be added.
Verify the connection
After saving, Qevlar runs a health check that confirms it can authenticate by acquiring a token. Role sufficiency (authorization) is not tested at this step — it is exercised on the first data read. If the check fails, work through, in order:
- The client secret value is correct and not expired.
- The role assignments target the app registration's service principal (not a user) at the workspace or resource-group scope.
- Role assignments can take a few minutes to propagate in Azure.
- For incident features, Subscription ID, Resource Group, and Workspace Name are all set and match the workspace exactly.
If a connection fails. During setup, the health check surfaces the error and its reason in the connector UI, and the connector cannot be used until it is resolved. During investigations, transient errors (HTTP 429, 500, 502, 503) are retried automatically with exponential backoff; if a source stays unavailable, Qevlar continues with the data it could reach and flags the source.
API reference
| Operation | HTTP | Endpoint | Tier |
|---|---|---|---|
| Query logs | POST | api.loganalytics.io/v1/workspaces/{workspaceId}/query | Read |
| Read incident | GET | …/Microsoft.SecurityInsights/incidents/{id} | Read |
| Read incident alerts | POST | …/incidents/{id}/alerts | Read |
| Read incident entities | POST | …/incidents/{id}/entities | Read |
| Add comment | PUT | …/incidents/{id}/comments/{commentId} | Write-back |
| Add tag | PUT | …/incidents/{id} (updates labels) | Write-back |
Management-plane base: https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}/providers/Microsoft.SecurityInsights · API version 2025-06-01