Correlate a Symptom Across Identity, Endpoint and Network

Tier: Advanced · Workflow area: Troubleshooting & diagnosis · ~40 minutes

Cross-system root-cause analysis is where AI assistance earns its Advanced tier: the model's real contribution is holding three unfamiliar log schemas in view at once and noticing that the timestamps line up. Your contribution is pulling honest evidence and verifying the correlation before anyone acts on it.

When to use

• Symptoms that straddle layersintermittent sign-in failures, "compliant device suddenly blocked", Conditional Access behaving differently by location, app access that works on Wi-Fi but not wired.
• Ping-pong ticketsidentity says "device problem", endpoint says "network problem", network says "identity problem". The correlated timeline is the tiebreaker.
• Post-change mysteriesafter a CA policy, compliance policy or network change, when something broke for some users and the intersection is unclear.

When NOT to use

• Single-layer symptomsa clear CA block with a stated policy name in the sign-in log needs pb-08, not a three-source correlation.
• Active account-compromise signalsrisky sign-in alerts and impossible-travel events belong to your security process; investigating them in general AI tooling is both a policy and an evidence-handling problem.

The recipe

1. 1.

   Fix the frame first: one user, one time window. Pick a concrete failure instance the user can timestamp ("blocked at ~09:12 today"). Correlation across "sometimes" fails; correlation across 08:30–10:00 on one day works.

2. 2.

   Pull the identity evidence — Entra sign-in logs. Console path: Entra admin center → Monitoring & health → Sign-in logs, filter by user and time, and open the failed entries — note the error code, failure reason, Conditional Access tab results, and the correlation ID. Or via Graph:

   Copy

   # App registration with AuditLog.Read.All; $TOKEN via your normal flow
   curl -s -H "Authorization: Bearer $TOKEN" \
     "https://graph.microsoft.com/v1.0/auditLogs/signIns?\$filter=userPrincipalName eq 'a.rao@yourco.com' and createdDateTime ge 2026-08-06T03:00:00Z&\$top=50" \
     | jq '[.value[] | {createdDateTime, appDisplayName, status: .status.errorCode,
            failureReason: .status.failureReason, ca: .conditionalAccessStatus,
            ip: .ipAddress, device: .deviceDetail}]' > signins.json
   

3. 3.

   Pull the endpoint evidence — Intune device state. Console path: Intune admin center → Devices → [device] → Hardware / Compliance; note compliance state, last check-in, and any policy with "Error" or "Conflict". Via Graph:

   Copy

   curl -s -H "Authorization: Bearer $TOKEN" \
     "https://graph.microsoft.com/v1.0/deviceManagement/managedDevices?\$filter=userPrincipalName eq 'a.rao@yourco.com'" \
     | jq '[.value[] | {deviceName, complianceState, lastSyncDateTime,
            operatingSystem, osVersion}]' > devices.json
   

   If your tenant streams to Log Analytics, Copilot-generated KQL is the fast path — ask Copilot in the portal for "sign-in failures for user X with device compliance state over the window", or write it directly:

   Copy

   SigninLogs
   | where UserPrincipalName == "a.rao@yourco.com"
   | where TimeGenerated between (datetime(2026-08-06T03:00:00Z) .. datetime(2026-08-06T05:00:00Z))
   | project TimeGenerated, AppDisplayName, ResultType, ResultDescription,
             ConditionalAccessStatus, IPAddress, DeviceDetail
   | order by TimeGenerated asc
   

   Treat Copilot-built KQL like any AI output: read it, check the table and column names against your workspace, run it, and confirm the row counts look sane before trusting the result set.

4. 4.

   Pull the network evidence — where was the user, on what path? This layer is usually thinnest: the egress IP from the sign-in log itself (is it the office egress or the VPN pool?), VPN session logs for the window, and a client-side capture if you have one (ipconfig /all and dsregcmd /status from the device at failure time). Even "user was on office Wi-Fi, egress should have been 203.0.113.10 but sign-ins show the VPN pool" is a decisive network fact.

5. 5.

   Correlate with AI — ranked hypotheses, each with its verification.

   Copy

   Correlate three evidence sets for a cross-system RCA.
   
   SYMPTOM: user intermittently blocked signing in to Outlook/Teams since
   Monday; works at home, fails "sometimes" in the office. One confirmed
   failure at 09:12 IST today.
   
   EVIDENCE A — Entra sign-in log extract (JSON): [paste signins.json]
   EVIDENCE B — Intune device state (JSON): [paste devices.json]
   EVIDENCE C — network context: office egress is 203.0.113.10; VPN pool is
   198.51.100.0/24; failing sign-ins show IPs from the VPN pool; dsregcmd
   shows AzureAdJoined YES, device ID matches Intune record.
   
   Produce:
   1. TIMELINE: merge all three sources into one timestamped sequence around
      the 09:12 failure. Flag timezone assumptions explicitly.
   2. HYPOTHESES: ranked candidate root causes. For each — the mechanism,
      which evidence supports it, which evidence it fails to explain, and
      the VERIFICATION: the exact log field, console path, or query that
      would confirm it.
   3. GAPS: what evidence would most improve the ranking.
   
   Rules: cite only fields present in the evidence. Error codes mean what
   Microsoft says they mean — if unsure of a code, say so rather than guess.
   

6. 6.

   Verify the top hypothesis in the consoles before acting. A typical strong output:

   Copy

   1. (Most likely) CA policy "Require compliant device" blocks when traffic
      egresses via VPN pool: VPN pool is not in the "Trusted locations" named
      location, and the device — compliant per Intune — fails the location-
      scoped policy variant. Supports: failures only from 198.51.100.x;
      ResultType 53003; CA tab shows policy P-04 failed. Does not explain: one
      success from VPN at 08:41 — check whether that was a refresh token, not
      an interactive auth.
      VERIFICATION: Entra → Conditional Access → P-04 → named locations; and
      the 08:41 entry's "incoming token type" field.
   

   Do the verification with your own eyes: open the policy, read the named-location list, check the 08:41 entry. Model error-code glosses are usually right and occasionally subtly wrong — the Entra sign-in error code lookup on Microsoft Learn is the authority. Only a console-confirmed hypothesis moves to remediation, and the fix (adding the VPN pool to trusted locations, adjusting the policy) goes through change control with the correlated timeline attached as justification.

7. 7.

   File the RCA. Timeline, confirmed cause, disconfirmed alternates and their evidence, and the change reference — into the ticket and the problem record. Cross-system RCAs are rare and expensive; a filed one is reusable the next three times the symptom shape recurs.

Make it yours

• Non-Microsoft identity (Okta, Google)same three-layer frame: Okta System Log (/api/v1/logs?filter=...) or Google Workspace login audit replaces Entra; MDM (Jamf, Workspace ONE) replaces Intune; the correlation prompt is unchanged.
• Hybrid AD environmentsadd a fourth evidence set: on-prem DC security events (4771/4768/4776) for the same window; Kerberos-vs-cloud auth divergence is a classic hidden cause.
• Copilot-forward tenantsSecurity Copilot / Intune Copilot can produce the per-layer summaries themselves; keep the merge-and-rank step in your own prompt so the cross-layer reasoning stays visible and checkable rather than buried in a vendor summary.

Quality check

• Timezone disciplineGraph returns UTC, your user speaks IST, network gear may log in local time; normalize before correlating, and make the model state its timezone assumptions (rule is in the prompt for a reason).
• Every hypothesis carries its disconfirming evidence tooa correlation story that explains everything and is contradicted by nothing has usually ignored something; the "does not explain" line is where the truth lives.
• Console truth over extract truthverify the winning hypothesis against the live consoles, not the JSON you pulled an hour ago; policies and device state move.
• Change control for the fix, sandbox for the testvalidate a proposed CA change with the What If tool and report-only mode before enforcement; a CA fix deployed hot to solve one user's ticket is how the next, bigger ticket gets created.