Microsoft Sentinel

Why: the workspace is where Sentinel queries the data from. Everything else in this guide lives inside the same resource group.

• Resource group: e.g. rg-sentinel-lab, region North Europe.
• Log Analytics workspace: e.g. law-arbiter-sentinel, same region as the resource group.
• Pricing tier: start on Pay-as-you-go. Move to a Sentinel Commitment Tier later if your ingest grows.

Microsoft Sentinel features (Workbooks, Hunting, Analytics Rules) are optional. Enable Sentinel on the workspace from its blade if you want them. Without it, data still lands and is queryable from the workspace via plain KQL.

Why: the DCE is the public URL Arbiter POSTs to. One DCE is enough; you will reuse it across both streams.

Portal search bar → Data Collection Endpoints→ + Create:

• Endpoint name: dce-arbiter-sentinel
• Subscription and resource group: same as the workspace
• Region: same as the workspace

Review and create. About 30 seconds. Once provisioned, open the DCE and copy the Logs Ingestion URL from the Overview tab:

https://dce-arbiter-sentinel-XXXX.northeurope-1.ingest.monitor.azure.com

Strip any trailing slash. Save this URL for Step 7.

Why: the Custom Table is the destination Sentinel queries from. The DCR sits in front of it and enforces the schema. The wizard creates both in one flow.

One Custom Table per stream. The walkthrough below covers auth log rejects; the security events flow is identical except for the table name and the sample file.

a. Grab the sample JSON

The wizard infers the table's column types from a sample file. Save the block below as arbiter_authlog_rejects_sample.json:

[
  {
    "TimeGenerated": "2026-05-21T14:30:12.000123Z",
    "event_id": 90342,
    "tenant_id": 201,
    "mac_address": "aabbccddeeff",
    "user_name": null,
    "nas_ip": "10.0.0.5",
    "nas_name": "core-sw-01",
    "nas_port": "GigabitEthernet0/1",
    "vlan_id": 30,
    "ssid": null,
    "ap_mac": null,
    "auth_method": "mab",
    "eap_type": null,
    "reason": "unknown MAC: no matching endpoint",
    "policy_name": "Default Deny",
    "auth_policy_name": "Wired MAB",
    "access_profile_name": "Quarantine",
    "monitor_mode": false,
    "monitor_coerced": false,
    "client_cert_cn": null,
    "client_cert_serial": null,
    "client_cert_issuer": null,
    "client_cert_issuer_org": null,
    "source": "arbiter.auth_log_rejects"
  }
]

For the security events stream, use this sample instead:

[
  {
    "TimeGenerated": "2026-05-21T14:30:00.123456Z",
    "event_id": 1042,
    "tenant_id": 201,
    "rule_name": "ssh-on-guest-vlan",
    "severity": "high",
    "mac_address": "aabbccddeeff",
    "nas_ip": "10.0.0.5",
    "nas_port_id": "GigabitEthernet0/1",
    "summary": "SSH (TCP/22) seen from a guest-VLAN endpoint",
    "details": {
      "flow_src": "192.168.30.42",
      "flow_dst_port": 22,
      "flow_proto": "tcp"
    },
    "source": "arbiter.security_events"
  }
]

b. Run the table-creation wizard

In the workspace blade, left nav → Tables→ + Create → New custom log (DCR-based). Fill in:

• Table name: ArbiterAuthLog(Azure appends _CL; do not type it yourself).
• Data collection rule: Create new, same resource group, name dcr-arbiter-authlog.
• Data collection endpoint: pick dce-arbiter-sentinel from Step 2.

Click Next. On the schema page, Browse for files and upload the sample JSON. The preview should show TimeGenerated as datetime and the rest as string / int / dynamic as appropriate.

Click Next → Create. Allow 1 to 2 minutes for the table to provision.

c. Copy the DCR identifiers

Once created, open dcr-arbiter-authlog and grab two values for Step 7:

• DCR immutable ID. Top toolbar → JSON View. Search for "immutableId"; the value looks like dcr-64c60e809eca44d1af23031db751157c.
• Stream name. Left nav → Data sources. The row is named Custom-ArbiterAuthLog_CL.

Arbiter authenticates as a confidential client application using OAuth 2.0 client credentials. Create one app registration; both streams can share it.

1. Search bar: Microsoft Entra ID → left nav App registrations → + New registration.
2. Name: Arbiter Sentinel Ingest (label only; pick whatever helps you).
3. Supported account types: Accounts in this organisational directory only (Single tenant).
4. Redirect URI: leave blank.
5. Register.

On the Overview tab, copy two values you will paste into Arbiter later:

• Application (client) ID: a GUID.
• Directory (tenant) ID: a different GUID (this is your Entra tenant identifier).

In the same app registration:

1. Left nav: Certificates & secrets.
2. Client secrets tab → + New client secret.
3. Description: arbiter-core (label only).
4. Expires: 24 months recommended. Azure emails the registration owner ahead of expiry. Shorter lifetimes are fine for tighter rotation policies; longer is unsupported.
5. Add.

The secret value appears once in the Value column, formatted like Aa1Bb2~Cc3Dd4.... Copy it immediately. If you navigate away without copying, the value is unrecoverable: delete the secret and create a new one.

Why: the Logs Ingestion API checks RBAC at two scopes. A missing role assignment is the most common reason a Sentinel target shows HTTP 403.

• DCE needs the role for the connection.
• DCR needs the role for the stream write. This is the strict check.

Do the steps below twice: once on dce-arbiter-sentinel, once on dcr-arbiter-authlog.

1. Open the resource.
2. Left nav → Access control (IAM).
3. + Add → Add role assignment.
4. Role: Monitoring Metrics Publisher→ Next.
5. Members: User, group, or service principal→ + Select members.
6. Search for Arbiter Sentinel Ingest. Pick the result with the service-principal icon (small blue square, not a user avatar). Click Select.
7. Review + assign.

Why: the SIEM target row is what tells the Arbiter forwarder where to ship events.

In the Arbiter admin portal, open the tenant you want shipping to Sentinel. Switch to the SIEM tab → + Add target.

Save the target, then click the Test paper-plane icon next to the row. The status flips to OK (green tick) within about 30 seconds on success.

If it stays red, hover the Error icon. The tooltip shows the exact HTTP response from Azure:

• 401: AAD credentials wrong (client ID, client secret or tenant ID).
• 403: role assignment missing or not yet propagated. See Troubleshooting below.
• 400: stream name typo or schema mismatch.

Why: verify the pipeline end-to-end in two stages before you trust it for production alerting.

a. Canary check (Test button)

In Arbiter, on the SIEM tab, click the paper-plane icon next to the target row. The forwarder posts a single synthetic event matching the stream's schema; the status flips to OK within about 30 seconds if everything is wired correctly.

Confirm it landed in Sentinel: open the workspace → Logs → paste:

ArbiterAuthLog_CL
| where TimeGenerated > ago(5m)
| project TimeGenerated, mac_address, reason

You should see one row with mac_address = 000000000000 and a reason starting with "Arbiter SIEM test event…".

b. Real data check

Real rejects from the tenant start flowing on the next 10-second cursor tick. Filter the canary out so you only see live data:

ArbiterAuthLog_CL
| where TimeGenerated > ago(15m)
| where mac_address != "000000000000"
| project TimeGenerated, mac_address, nas_name, auth_method, reason, auth_policy_name
| order by TimeGenerated desc

If your tenant has any failing auths (blocked MABs, expired certs, default-deny matches), rows appear here within a minute or two of the auth happening. If nothing's appearing, check the Auth log tab in the Arbiter portal first to confirm rejects are actually being produced.

Expected latency

Why: Sentinel's value over a passive log store is that you can render the data into Workbooks and trigger Analytics Rules. Starter queries below.

// Failed-auth rate by hour, useful for a Workbook tile
ArbiterAuthLog_CL
| where TimeGenerated > ago(7d)
| summarize rejects = count() by bin(TimeGenerated, 1h)
| render timechart

// Top reject reasons over the last 24 hours
ArbiterAuthLog_CL
| where TimeGenerated > ago(24h)
| summarize count() by reason
| order by count_ desc
| take 10

// Endpoints producing the most rejects (potential misconfig or attack)
ArbiterAuthLog_CL
| where TimeGenerated > ago(24h)
| summarize attempts = count(), reasons = make_set(reason) by mac_address
| order by attempts desc
| take 20

To turn one of these into an alert, go to Sentinel → Analytics→ + Create→ Scheduled query rule. Paste the query, set a threshold (e.g. "trigger when more than 20 rejects from the same MAC in 5 minutes") and an action (email, Teams, ServiceNow ticket, etc.).