Identity Monitoring: Logs, KQL & Secure Score

Identity Monitoring and Secure Score

Simple explanation

Monitoring is like the security cameras and health dashboard for your identity system.

Imagine your building has three camera feeds: one at the front door recording who enters and leaves (sign-in logs), one in the admin office recording all changes to keys and access cards (audit logs), and one tracking the badge-printing machine (provisioning logs). Right now, these recordings are on a short loop — you only keep a few days. Diagnostic settings let you save them long-term to a video archive (Log Analytics).

KQL is like a smart search bar for those recordings — you can ask “show me everyone who entered after midnight last week” and get instant results. Identity Secure Score is your building’s safety rating — it tells you what to fix to be more secure.

The three log types

Understanding what each log captures is a common exam question:

Feature	Sign-in Logs	Audit Logs	Provisioning Logs
What it records	Authentication events (successful and failed sign-ins)	Directory changes (user created, role assigned, policy changed)	User provisioning to/from apps (SCIM, HR-driven)
Key data points	User, app, location, device, CA policy result, MFA status, risk level	Who changed what, when, old value vs new value	Source system, target system, user matched, action taken, status
Retention (Entra portal)	30 days (P2) or 7 days (Free)	30 days (P2) or 7 days (Free)	30 days (P2) or 7 days (Free)
Log Analytics table	SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs	AuditLogs	AADProvisioningLogs
Common investigation	Failed sign-ins, risky sign-ins, MFA failures, location anomalies	Unauthorized changes, role assignments, policy modifications	Provisioning failures, attribute mapping issues

Exam tip: Sign-in log types

There are actually four sign-in log categories:

Interactive user sign-ins — a human typing credentials
Non-interactive user sign-ins — token refreshes, background SSO
Service principal sign-ins — apps authenticating with client credentials
Managed identity sign-ins — Azure resources authenticating via managed identity

The exam may ask which log captures a specific scenario. A background token refresh is non-interactive, not interactive. An Azure Function calling Microsoft Graph with a managed identity appears in managed identity sign-ins.

Configuring diagnostic settings

By default, logs only live in the Entra portal for 7–30 days. To keep them longer and query them with KQL, you must configure diagnostic settings.

Three destinations:

Destination	Purpose	Best For
Log Analytics workspace	Store and query with KQL, build workbooks, set alerts	Primary destination for monitoring and investigation
Azure Storage account	Long-term archival at low cost	Compliance — keeping logs for years
Azure Event Hubs	Stream to SIEM or external systems	Integration with Sentinel, Splunk, or other SIEM tools

You can send logs to multiple destinations simultaneously — for example, Log Analytics for active querying AND a storage account for long-term archival.

Scenario: Priya configures diagnostic settings

🔐 Priya configures diagnostic settings for Meridian Health:

Navigate to: Entra admin center → Monitoring → Diagnostic settings → Add diagnostic setting
Name: “MeridianHealth-IdentityLogs”
Logs to send: All four sign-in types + Audit logs + Provisioning logs
Destination 1: Log Analytics workspace (“MeridianHealth-LogAnalytics”) — for KQL queries and workbooks
Destination 2: Storage account (“meridianlogarchive”) — for 7-year retention (healthcare compliance)

Now all identity logs flow to both destinations. Priya can query recent events in Log Analytics and archive older logs in cheap storage.

Cost tip: Log Analytics charges per GB ingested. Sign-in logs (especially non-interactive) generate the most data. Priya monitors ingestion volumes and may exclude non-interactive sign-ins if costs are too high and they’re not needed for investigation.

Exam tip: Prerequisite for diagnostic settings

To configure diagnostic settings, you need:

In Entra ID: Security Administrator role (Security Reader and Reports Reader can view logs but cannot create diagnostic settings)
In Azure: Contributor or higher on the destination resource (Log Analytics workspace, storage account, or Event Hub)
The Log Analytics workspace must exist before you can select it as a destination

KQL queries for identity investigation

Once logs are in Log Analytics, you can query them with KQL (Kusto Query Language). Here are practical examples:

Find failed sign-ins in the last 24 hours:

SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != "0"
| summarize FailedAttempts = count() by UserPrincipalName
| order by FailedAttempts desc

Find sign-ins from unfamiliar locations:

SigninLogs
| where TimeGenerated > ago(7d)
| where LocationDetails.countryOrRegion != "NZ"
| project TimeGenerated, UserPrincipalName, AppDisplayName, LocationDetails.city
| order by TimeGenerated desc

Find recent role assignments (who got admin roles):

AuditLogs
| where TimeGenerated > ago(7d)
| where OperationName == "Add member to role"
| project TimeGenerated, InitiatedBy.user.userPrincipalName, TargetResources[0].displayName

Scenario: Anika investigates suspicious sign-ins with KQL

🛡️ Anika receives an alert about unusual sign-in activity at Meridian Health. She opens Log Analytics and runs:

SigninLogs
| where TimeGenerated > ago(1h)
| where RiskLevelDuringSignIn in ("high", "medium")
| project TimeGenerated, UserPrincipalName, AppDisplayName, IPAddress, LocationDetails.city, RiskLevelDuringSignIn, Status.errorCode
| order by TimeGenerated desc

She finds 3 high-risk sign-ins from an IP in a country Meridian Health doesn’t operate in. She cross-references with the audit logs:

AuditLogs
| where TimeGenerated > ago(1h)
| where InitiatedBy.user.userPrincipalName == "compromised.user@meridianhealth.com"
| project TimeGenerated, OperationName, TargetResources

No suspicious changes found — the Conditional Access policy blocked the sign-ins. Anika documents the investigation and recommends blocking the IP range.

Exam tip: KQL basics for the exam

You don’t need to be a KQL expert for SC-300, but you should know:

where — filters rows (like SQL WHERE)
project — selects columns (like SQL SELECT)
summarize — aggregates data (like SQL GROUP BY)
order by — sorts results
ago() — time function (e.g., ago(24h), ago(7d))
SigninLogs and AuditLogs are the main table names

The exam tests whether you can read a KQL query and understand what it does — not write complex queries from scratch.

Workbooks and reporting

Entra ID workbooks are pre-built and custom visual dashboards powered by Log Analytics data:

Built-in Workbook	What It Shows
Sign-in analysis	Sign-in trends, failure rates, CA policy impact
Conditional Access insights	Which CA policies are firing, gaps in coverage
Authentication methods	MFA adoption, method types, registration status
Sensitive operations	High-risk admin actions, privilege escalation
Cross-tenant access	B2B sign-in activity from external tenants

To use workbooks: Entra admin center → Monitoring → Workbooks. Select a template or create custom.

Reporting options:

Entra admin center → Usage & insights — built-in reports (authentication methods, MFA usage)
Workbooks — visual dashboards from Log Analytics data
KQL export — export query results to CSV
Microsoft Sentinel — advanced SIEM with automated response (if Event Hubs are configured)

Identity Secure Score

Identity Secure Score is a percentage that measures how well your Entra ID configuration aligns with Microsoft’s security best practices.

How it works:

Score ranges from 0% to 100%
Based on improvement actions — each action has a max score impact
Actions are prioritised by impact and implementation effort
Score updates automatically as you implement recommendations

Common improvement actions:

Recommendation	Impact	What to Do
Enable MFA for all users	High	Deploy Conditional Access requiring MFA
Eliminate standing admin access	High	Convert active admin assignments to eligible in PIM
Block legacy authentication	Medium	Create CA policy blocking legacy auth protocols
Require MFA for admin roles	High	CA policy or PIM activation requiring MFA for admins
Enable password protection	Medium	Configure banned password lists
Use least-privilege admin roles	Medium	Replace Global Admin with specific roles (User Admin, etc.)

Scenario: Priya improves Meridian Health's Secure Score

🔐 Priya checks Meridian Health’s Identity Secure Score: 62%

Top recommendations:

Enable MFA for all users (+15 points) — Priya creates a CA policy requiring MFA for all users, all apps
Ensure all admins use PIM (+8 points) — She converts the remaining 4 active admin assignments to eligible
Block legacy authentication (+6 points) — Creates a CA policy blocking legacy auth

After implementing all three: Score rises to 85%. The remaining 15% includes actions like enabling Entra ID Password Protection (custom banned passwords) and requiring phishing-resistant MFA.

Priya schedules a monthly check of the Secure Score dashboard to catch new recommendations.

Exam tip: Secure Score vs Defender Secure Score

Don’t confuse Identity Secure Score (in Entra ID — focuses on identity configuration) with Microsoft Secure Score (in Microsoft Defender — broader security posture across M365). The SC-300 exam tests Identity Secure Score specifically.

Identity Secure Score is found in the Entra admin center under Protection → Identity Secure Score (or Identity → Overview in some portal versions).

Video Lesson

🎬 Video coming soon

Identity Monitoring: Logs, KQL & Secure Score

~12 min