Entra ID custom logging and alerts: From diagnos...

Microsoft Entra ID writes a detailed record of everything that matters for identity security, such as who signed in, from where, whether MFA was satisfied, what an admin changed, and which app requested a token. The catch is how long it keeps that record. On the free tier, sign-in and audit logs are retained for 7 days, whereas with Entra ID P1 or P2, 30 days. That is fine right up until you need to investigate something that happened five weeks ago, correlate a suspicious sign-in, or find out the moment a break-glass account is used instead of finding out a month later.

The suggested fix for this involves streaming Entra's logs into a Log Analytics workspace you own, under an Azure Subscription within your tenant. This has a very small cost and allows those logs to be queried with KQL. Once the logs are in a Log Analytics Workspace, custom alerting becomes an option with Azure Logic Apps. Here is how these pieces fit together.

Step one: Stream Entra logs to Log Analytics

A few things worth knowing up front:

• You need an Azure subscription and a Log Analytics workspace created ahead of time. To configure the Microsoft Entra diagnostic setting, you need at least the Security Administrator role in Microsoft Entra ID. You also need the appropriate Azure permissions to use the destination workspace; creating the workspace typically requires Log Analytics Contributor or Monitoring Contributor access.
• Log Analytics is one of four destinations. You can also stream to an Event Hub (to feed a third-party SIEM), archive to a Storage account, or send to a partner solution. A tenant supports up to five diagnostic settings, so different logs can go to different places.
• Licensing is the one real gotcha. Streaming the sign-in log categories requires Entra ID P1 or P2. Without it, the portal blocks the SigninLogs selection. Confirm your tenant's licensing before you plan around this. Microsoft Entra ID P1 is included in bundled license packages such as Microsoft Business Premium.

In the Microsoft Entra admin center, go to Entra ID > Monitoring & health > Diagnostic settings, then choose Add diagnostic setting. Give it a name, tick the log categories you want under Logs, select Send to Log Analytics workspace under Destination details, pick the subscription and workspace, and Save. Data usually starts landing within about 15 minutes.

What you can actually send

The category list is broader than most people realize. The two that everyone should send are AuditLogs (every change to users, groups, roles, apps, and licenses) and SignInLogs (interactive user sign-ins). Beyond those, you can stream:

• NonInteractiveUserSignInLogs, ServicePrincipalSignInLogs, and ManagedIdentitySignInLogs. This includes sign-in activity for background tokens, apps/service principals, and managed identities.
• ProvisioningLogs. This contains logs for user and group provisioning to and from apps such as Workday or ServiceNow.
• RiskyUsers and UserRiskEvents from Entra ID Protection.
• MicrosoftGraphActivityLogs. Every HTTP call into your tenant through Microsoft Graph.

There are more specialized categories too (AD FS sign-ins, Global Secure Access traffic and health, custom security attribute audits). Send all of the items that you may want to query. Every category you enable is data you ingest and pay to retain.

One thing that trips people up: the category names you tick in diagnostic settings are not always the KQL table names you query. SignInLogs and AuditLogs keep their names, but most of the rest are prefixed with AAD. For example, NonInteractiveUserSignInLogs lands in the AADNonInteractiveUserSignInLogs table, ServicePrincipalSignInLogs in AADServicePrincipalSignInLogs, and ProvisioningLogs in AADProvisioningLogs. When a query returns nothing, a wrong table name is often why.

Querying the data with KQL

With logs flowing, you can then query them in Entra admin center > Monitoring & health > Log Analytics, or from the Logs blade on the workspace itself. The least-privileged role to run these queries is Reports Reader. This is where "custom logging" becomes custom detection. Anything you can express in KQL, you can watch for. Two quick examples.

A spike of failed sign-ins from a single user and IP in the last hour:

SigninLogs
| where TimeGenerated > ago(1h)
| where ResultType != "0"
| summarize FailedAttempts = count() by UserPrincipalName, IPAddress
| where FailedAttempts > 10

A ResultType of "0" means success, so anything else is a failed attempt.

Someone being added to a privileged directory role:

AuditLogs
| where OperationName == "Add member to role"
| where Result == "success"
| project TimeGenerated, InitiatedBy, TargetResources

Get the query returning exactly what you want in the editor first. A clean query is the foundation of a clean alert. If it is noisy here, it will be noisy in your inbox.

Turning queries into alerts

There are two solid ways to go from a working query to an alert, and the right choice depends on how much control you want over what happens next.

Option 1 - An Azure Monitor log search alert rule with an action group.

In Azure Monitor, create an alert rule scoped to your Log Analytics workspace, choose the custom log search signal, and paste your KQL. Set the measure to table rows and fire when the count is greater than zero on whatever evaluation frequency fits (example: every 5 or 15 minutes) with a matching lookback window. When it fires, the rule triggers an action group, and the action groups natively support a Logic App action alongside email, SMS, and webhooks. The alert reaches your Logic App as a structured payload, ready to act on. This is the right default for most "notify me when X happens" cases.

Option 2 - A Logic App on a schedule, querying the workspace directly.

Sometimes an alert rule is not the right shape. You may want a formatted daily digest, a multi-step workflow, or a chart in the message rather than a bare "something fired." For that, build the Logic App around a Recurrence trigger and use the Azure Monitor Logs connector's Run query and list results action to run your KQL on a schedule. This connector is the current, preferred one. It replaces the older Azure Log Analytics connector and authenticates with a managed identity, so there are no API keys to manage. Keep the platform limits in mind: a query cannot return more than 500,000 rows or 64 MB, cannot run longer than 10 minutes, and the connector is capped around 100 calls per minute. So keep the KQL tight and the schedule sensible.

What Logic Apps let you do that a plain email can't

The reason to route alerts through a Logic App rather than a bare email action is everything you can do once the payload is in hand. From a single workflow you can:

• Post a formatted card to a Microsoft Teams channel or Slack, so the right team sees it where they already work.
• Open a ticket automatically in ServiceNow, Jira, or Azure DevOps, with the alert details pre-filled.
• Call Microsoft Graph to take action. For example, disable a user or revoke their tokens when a high-confidence detection fires.
• Enrich the alert with other data (a user's manager, device compliance, geolocation) before deciding what to do.
• Add your own throttling and de-duplication so a noisy condition doesn't page someone forty times.

Keep an eye on cost

None of this is free, but it is easy to keep reasonable. Log Analytics bills for data ingestion and retention by the gigabyte, so send the categories you will use rather than all them, and set workspace retention deliberately. Azure Monitor alert rules are billed per rule, and cost rises as evaluation frequency increases. A rule that runs every minute costs more than one that runs every fifteen. Logic Apps bill per action on the Consumption plan. Right-sized, a small workspace with a handful of targeted alerts is an inexpensive, high-leverage addition.

The bottom line

Getting Entra ID logs into a Log Analytics workspace is one of the quickest high value wins available to an identity team. It is the first step to retaining your Microsoft Entra logs, which automatically expire and become inaccessible in a 30-day window. The payoff is what you stack on top: targeted KQL queries, wired through Logic Apps that notify the right people in the right place. Set it up before an incident, because the logs you didn't export are the ones you can't get back.