Microsoft 365 EntraID | Monitoring and integrity

– EntraID Monitoring: Protocols, Diagnosis & Health in Detail

“My login doesn’t work.” – When this sentence is uttered, the detective work begins for you as an administrator. Is it the password? Does a conditional access policy apply? Or is the account blocked?

The Monitoring & Health in Microsoft Entra is your cockpit for responses. It’s the place where you don’t configure, but analyze. In this article, we’ll go through the most important menu items so that you immediately know where to click in an emergency.

Prerequisites: Licenses, roles, and latencies

The license factor (Free vs. P1 vs. P2)

Before we dive into the logs, let’s take a look at the licenses, because they determine how far into the past you can look.

• Entra ID Free: Stores reports and logs for 7 days only. Security reports are often not available at all.
  
• Entra ID P1: Stores logs for 30 days. You’ll see sign-ups and audits, but no detailed risk events.
  
• Entra ID P2: Also stores for 30 days, but unlocks the Identity Protection Logs . Only with P2 you can see details about “risk-based logins” (e.g. impossible relocation) and “risk users”.

Professional tip for long-term archiving: If you need data longer than 30 days (e.g. for audits or ISO certifications), you need to export it (more on that later).

Roles (Least Privilege)

You don’t need to be a Global Administrator to read logs. Keep the rights minimal:

• Security Reader: Ideal for the security team.
• Global Reader: The “read-only” admin for almost everything.
• Reports Reader: Granular access to reports only.

Patience is required: Latency

A common ticket phenomenon: A user reports an error, you immediately look at the log and see … nothing. The logs are not real-time.

• Login logs: May have a delay of 2 to 5 minutes .
• Deployment logs: Sometimes up to 2 hours.
• Risk Events (P2): Detecting complex patterns (e.g., leaked credentials) can take up to 24 hours (offline detection).

Sign-in Logs

This is where you’ll probably spend 90% of your time troubleshooting. Microsoft divides this view into different tabs to make the sheer mass of data manageable.

Scenario monitoring: Filtering correctly

The most common mistake: Just scroll wildly through the list. Instead, use the Add Filter function to check scenarios specifically:

• Scenario “Failed logins”: Set the filter to Status = Error. This way you block out the “noise” of the successful logins.
  
• Conditional Access scenario: If you want to know which policy is blocking, click on the corresponding log entry and select the Conditional Access tab. Here you can immediately see the status of each policy: “Not applied”, “Success” or “Failure”.

Interactive User Logins

This is the classic: A user sits in front of the screen and enters username/password or uses MFA. What you’re looking for here:

1. Status: Success or failure?
2. Error code: Click on a failed login. The Basic Information tab often gives you the reason directly (e.g. “MFA required” or “Account disabled”).
3. Fault diagnosis: In the Conditional Access tab, check to see if a geo-blocking rule or device compliance policy has denied access.

Non-interactive user logins

These logs are often overlooked, but they often make up the majority of traffic. These are logins that happen in the background without the user interacting (e.g. when an app uses a refresh token to extend the session).

Practical tip: If a user says: “It worked yesterday, today no longer (without me doing anything)”, the mistake is often here. Check to see if refresh tokens are being rejected – for example, because the password has been changed and the old tokens have become invalid.

Service Principals & Managed Identities

It’s not just people who sign up. In modern environments, you often have more machine identities than users:

• Service principals: Apps or scripts that work with client secrets or certificates.
  
• Managed Identities: Azure resources that authenticate each other.
  
• Why this is important: If nightly backups, automations or backend processes suddenly fail, you won’t find the cause in the user logs, but right here.

Audit Logs

While the login logs answer the “Who is taking it?”, the monitoring logs clarify the “Who changed what?”. This is your compliance log for internal change management. Each entry follows a clear scheme that helps you reconstruct events:

• Actor: Who made the change? (e.g. admin John Doe or an automated service principal).
  
• Target: Which object was manipulated? (e.g. the security group “Marketing” or the user “Lisa Müller”).
  
• Activity: What exactly has been done? (e.g., Update Group, Reset User Password, or Assign Application Role).

Typical use case: A user complains that they suddenly no longer have access to an important app. A look at the audit log often reveals: A colleague (or a script) accidentally removed the user from the authorizing security group last night. Case solved, without long troubleshooting in the app itself.

Provisioning Logs

Do you use automatic user provisioning (SCIM) to SaaS apps like Salesforce, ServiceNow, or Dropbox? Or do you synchronize users from an HR system like Workday (Inbound Provisioning)? Check the status of these background syncs.

The entries are divided into three categories that you need to know:

• Success: The user has been successfully created or updated in the target app.
  
• Skipped: No change has been made here. This is often not an error, but means: The user already exists identically in the target system, the necessary attributes for the creation are missing, or the user is not in the defined scope of the synchronization.
  
• Failure: The synchronization failed. In most cases, the API of the target app rejected the request – for example, due to missing licenses in the target application or connection problems.

Log Analytics & Export

This is where you come up against one of the hardest limits of Entra ID: the data is deleted after a maximum of 30 days by default. This is not enough for a professional environment. Security incidents are often only discovered after months (on average after more than 200 days!). Without external storage, you’re left without evidence.

You can therefore use the menu item Diagnostic Settings to extract the data streams to three different destinations:

• Log Analytics Workspace (Azure Monitor): Microsoft’s analytics tool. It allows you to perform complex queries using the KQL (Kusto Query Language).
  • Use-Case: Analysis and alerting. Here you build queries like: “Alert me immediately if 50 failed logins happen within 1 minute.”
    
• Storage Account: The cost-effective variant for pure long-term archiving (cold storage). The data ends up here as JSON files.
  • Use-Case: Compliance. Ideal for meeting legal retention periods (e.g., 6 or 12 months) without spending a lot of money on expensive analytics storage.
    
• Partner solutions (via Event Hub): Many companies use specialized tools such as AdminDroid or SIEM systems such as Splunk.
  • Use-Case: Central monitoring. These tools import the data (often via Azure Event Hub) and prepare it graphically for management or the SOC.

Usage & Insights

This area helps you with strategic decisions and security assessments. Instead of looking for individual mistakes, you look at the big picture and recognize trends in your organization.

Here are answers to questions that the CFO or CISO asks you:

• Authentication Methods: How many users still use insecure methods such as SMS or voice calls for MFA? Use this data to target your campaigns to move to more secure methods (Microsoft Authenticator App or FIDO2 keys).
  
• Application Activity: Which registered enterprise apps are no longer used at all? This helps you massively to clean up the application landscape (“prevent app sprawl”) and possibly save unnecessary license costs for third-party tools.

Bulk operations

If you create many users at the same time via the GUI (e.g. via CSV upload) or add group members, these jobs run asynchronously in the background.

If your browser crashes or you accidentally close the window, progress is not lost. In this menu item you will find the status of all bulk transactions of the last few days. The most important point here: You can download the result file. In it, you can see line by line which entry from your CSV was successfully processed and which one failed (including the reason for the error).

Conclusion: First look, then screw

The Monitoring & Health Center is the heart rate monitor in your area. Get into the habit of looking first, then screwing when you have problems

The Monitoring & Health Center is the heart rate monitor in your area. Get into the habit of not tweaking settings wildly when you have problems, but to look at the logs first.

• In case of login problems: Login logs (especially the Error Cause & Conditional Access tabs).
• In case of unexplained changes: Audit logs.
• For safety: Export the logs to a workspace to keep them for more than 30 days.

» To the main article: Data protection in Microsoft Entra

further links

This post is also available in: