Access failed.
What does the evidence say?

An incident is a hypothesis until the logs support it.

Microsoft Entra records identity events across different log families. A successful sign-in is not the same as permission to use an app. An audit record is not proof the change was approved. A provisioned account isn't evidence the user can sign in. This guide makes those boundaries practical.

Three core log families. More than one kind of sign-in.

For a focused ticket, start in Microsoft Entra admin center → Entra ID → Monitoring & health, then open Sign-in logs, Audit logs or Provisioning logs. You generally need at least a Reports Reader role, but individual features, log export destinations and advanced reports have separate licensing and role requirements.

Start narrow. Correlate before you change.

Most identity troubleshooting should begin with a targeted user, application and UTC time. Jumping directly to resetting passwords or disabling a policy can make the problem harder to understand and can reduce protection.

Where the evidence lives changes what you can do with it.

Entra activity logs are available natively for a license-dependent retention window. To analyze patterns over longer periods, administrators can configure Diagnostic settings to send selected categories to other destinations. Microsoft documents Security Administrator as the least-privileged Entra role for configuring these settings, with separate destination-side permissions and prerequisites.

Typical setup: create the destination, open Entra ID → Monitoring & health → Diagnostic settings, select activity categories, configure routing and permissions, then generate a known test event and confirm it arrives. Routing does not recreate older records. Estimate ingestion, retention and export costs before enabling a large volume of categories.

Turn log records into an answer.

Azure Monitor Log Analytics uses Kusto Query Language (KQL). Read the query from top to bottom: start with a table, filter using where, choose columns with project, and aggregate with summarize and bin. Each pipeline step transforms the previous result; it isn't a Microsoft Graph permission command or a change to tenant settings.

These queries use Microsoft-documented table names and common fields. The example address is fictitious. Inspect the active workspace schema before adapting queries: fields, ingestion latency and feature-specific tables vary with configuration.

SigninLogs
| where TimeGenerated >= ago(7d)
| where UserPrincipalName =~ "morgan@northstar.example"
| where AppDisplayName == "Expense Portal"
| project TimeGenerated, UserPrincipalName,
          AppDisplayName, ResultType, ConditionalAccessStatus
| order by TimeGenerated desc

SigninLogs
| where TimeGenerated >= ago(7d)
| where ResultType != 0
| summarize Failures=count() by AppDisplayName
| order by Failures desc

AuditLogs
| where TimeGenerated >= ago(7d)
| where OperationName contains "policy"
| extend Actor=tostring(InitiatedBy.user.userPrincipalName)
| project TimeGenerated, Actor, OperationName, Result
| order by TimeGenerated desc

AADProvisioningLogs
| where TimeGenerated >= ago(7d)
| where ResultType == "Failure"
| summarize Failures=count() by JobId, ProvisioningAction
| order by Failures desc

AADProvisioningLogs
| where TimeGenerated >= ago(7d)
| summarize Events=count()
    by ProvisioningAction, bin(TimeGenerated, 1d)
| order by TimeGenerated desc

Once you understand the query structure, try the KQL Workbench to test it against fictional sign-in and audit evidence.

Read the logs. Prove your next step.

Explore three Northstar scenarios involving sign-in failure, policy audit and SaaS provisioning. Choose a grounded KQL example, inspect matching fictional records and select the most defensible investigation action.

SigninLogs
| where TimeGenerated >= datetime(2026-11-05T00:00:00Z)
| project TimeGenerated, UserPrincipalName, AppDisplayName, ResultType, ConditionalAccessStatus
| order by TimeGenerated desc

Good charts reveal questions. They don't close incidents.

Entra workbooks use Azure Monitor to visualize trends such as sign-in health, Conditional Access outcomes, and provisioning issues. Public templates and custom KQL views help administrators compare periods and share repeatable views. Microsoft currently documents Entra P1, a workspace containing the necessary data, and appropriate roles as prerequisites for Entra workbooks.

Identity Secure Score summarizes how closely tenant settings align with Microsoft's security recommendations. It helps prioritize improvement work, but isn't a real-time threat verdict or a pass/fail statement about one account. Evaluate prerequisites and business effects of each recommendation, make an approved change and validate the specific result.

Verify the configuration. Keep the investigation grounded.

Microsoft Learn is the source for current field names, role requirements and license details. Use these documents alongside the fictional JoeLearns casework.