Frequently asked questions around Microsoft Entra monitoring and health

See Microsoft Entra ID licensing to upgrade your Microsoft Entra edition.

If you already have activity log data as a free license, then you can see it immediately. If you don't have any data, then it takes up to three days for the data to show up in the reports.

If you recently switched to a Premium version (including a trial version), you can see data up to seven days initially. When data accumulates, you can see data for the past 30 days.

The least privilege role to view audit and sign-in logs is Reports Reader. Other roles include Security Reader and Security Administrator.

Sign-in and audit logs are both available for routing through Azure Monitor. B2C-related audit events are currently not included. For more information, see Microsoft Entra activity log integrations and the Graph API activity log overview.

Microsoft 365 and Microsoft Entra activity logs share many directory resources. If you want a full view of the Microsoft 365 activity logs, you should go to the Microsoft 365 admin center to get Office 365 Activity log information. The APIs for Microsoft 365 are described in the Microsoft 365 Management APIs article.

Several factors determine the number of logs you can download from the Microsoft Entra admin center, such as browser memory size, network speeds, and Microsoft Entra reporting APIs loads. Generally, data sets smaller than 250,000 for audit logs and 100,000 for sign-in and provisioning logs work well with the browser download feature. Depending on the number of fields you included, this number could vary. If you face issues completing large downloads in the browser, use the reporting API to download the data or send the logs to an endpoint through diagnostic settings.

The active filters in the Microsoft Entra admin center when you begin the download determine the specific set of logs you can download. For example, filtering to a specific user in the Microsoft Entra admin center mean your download pulls logs for that specific user. The columns in the downloaded logs do not change. The output contains all details of the audit or sign-in log, regardless of the columns you customized in the Microsoft Entra admin center.

Depending on your license, Microsoft Entra ID stores activity logs for between 7 and 30 days. For more information, see Microsoft Entra report retention policies.

The Diagnostic settings storage retention feature is being deprecated. For details on this change, see Migrate from diagnostic settings storage retention to Azure Storage lifecycle management.

At this time, there isn't a specific activity in the audit logs for license purchases or enablement. However, you might be able to correlate the "Onboard resource to PIM" activity from the "Resource Management" category to the purchase or enablement of a license. This activity might not always be available or provide the exact details.

The signInActivity resource is used to find inactive users who haven't signed in for some time. It doesn't update in near real time. If you need to find the user's last sign-in activity more quickly, you can use the Microsoft Entra sign-in logs to see near real time sign-in activity for all your users.

The CSV includes sign-in logs for the type of sign-ins you selected. Data that is represented as a nested array in the Microsoft Graph API for sign-in logs is not included. For example, Conditional Access policies and report-only information aren't included. If you need to export all the information contained in your sign-in logs, use the Export Data Settings feature.

It's also important to note the columns included in the downloaded logs don't change, even if you customized the columns in the Microsoft Entra admin center.

Microsoft Entra ID might redact part of an IP address in the sign-in logs to protect user privacy when a user might not belong to the tenant viewing the logs. This action happens in two cases:

• During cross tenant sign ins, such as when a CSP technician signs into a tenant that CSP manages.
• When our service wasn't able to determine the user's identity with sufficient confidence to be sure the user belongs to the tenant viewing the logs.

Microsoft Entra ID redacts Personally Identifiable Information (PII) generated by devices that don't belong to your tenant to ensure customer data. PII doesn't spread beyond tenant boundaries without user and data owner consent.

There are several reasons sign-in entries might be duplicated in your logs.

• If a risk is identified on a sign-in, another nearly identical event is published immediately after with risk included.
• If MFA events related to a sign-in are received, all related events are aggregated to the original sign-in.
• If partner publishing for a sign-in event fails, such as publishing to Kusto, an entire batch of events is retried and published again, which might result in duplicates.
• Sign-in events that involve multiple Conditional Access policies might be split into multiple events, which can result in at least two events per sign-in event.

The TimeGenerated field in Log Analytics is the time the entry was received and published by Log Analytics. Remember, in order for your logs to appear in Log Analytics, you have to configure diagnostics settings to send the logs to the Log Analytics workspace. That process takes time, so the TimeGenerated field might not match the actual time of the sign-in.

To confirm the date and time match the sign-in, look for the CreatedDateTime field a little further down in the Log Analytics results. The AuthenticationDetails fields can also be expanded to see the exact time of the sign-in. The time in Log Analytics appear in UTC, but the time in the sign-in logs in the Microsoft Entra admin center appear in local time, so you might need to adjust.

Non-interactive sign-ins can trigger a large volume of events every hour, so they're grouped together in the logs.

In many cases, non-interactive sign-ins have all the same characteristics, except for the date and time of the sign-in. If the time aggregate is set to 24 hours, the logs appear to show the sign-ins at the same time. Each of these grouped rows can be expanded to view the exact time stamp.

There are several reasons why sign-in entries might display User IDs, Object IDs, or GUIDs in the username field.

• With passwordless authentication, User IDs appear as the username. To confirm this scenario, look at the details of the sign-in event in question. The authenticationDetail field says passwordless.
• The user authenticated but has not yet signed in. To confirm, there's an error code 50058 that correlates with an interrupt.
• If the username field shows 000000-00000-0000-0000 or something similar, there could be tenant restrictions in place, preventing the user from signing in to the selected tenant.
• Multifactor authentication sign-in attempts are aggregated with multiple data entries, which might take longer to display properly. Data might take up to two hours to fully aggregate, but rarely takes that long.

No, in general 90025 errors are resolved by an automatic retry without the user noticing the error. This error can occur when an internal Microsoft Entra subservice hits its retry allowance and doesn't indicate your tenant is being throttled. These errors are usually resolved by Microsoft Entra ID internally. If the user is unable to sign in due to this error, manually trying again should resolve the issue.

If the Service Principal ID has the value “0000000-0000-0000-0000-000000000000" there's no Service Principal for the client application in that instance of authentication. Microsoft Entra no longer issues access tokens without a client Service Principal, except for a few Microsoft and non-Microsoft applications.

If the Resource Service Principal ID has the value “0000000-0000-0000-0000-000000000000," there's no Service Principal for the resource application in that instance of authentication.

This behavior is currently allowed only for a limited number of resource apps.

You can query for instances of authentication without a client or resource Service Principal in your tenant.

• To find instances of sign-in logs for your tenant where a client Service Principal is missing, use the following query:

  https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and servicePrincipalId eq '00000000-0000-0000-0000-000000000000'
  

• To find instances of sign-in logs for your tenant where a resource Service Principal is missing, use the following query:

  https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq 'servicePrincipal') and resourceServicePrincipalId eq '00000000-0000-0000-0000-000000000000'
  

You can also find these sign-in logs in Microsoft Entra admin center.

• Sign in to the Microsoft Entra admin center.
• Browse to Identity > Monitoring & health > Sign-in logs.
• Select Service Principal Sign-ins.
• Select an appropriate time frame in the Date field (last 24 hours, 7 days, and so on).
• Add a filter and select Service Principal ID and provide the value '00000000-0000-0000-0000-000000000000' to get instances of authentication with no client Service Principal.

If you wish to control how authentication works in your tenant for specific client or resource apps, follow instructions in the Restrict Microsoft Entra app to a set of users article.

Some non-interactive sign-ins were made available before the non-interactive sign-in logs were available in public preview. These non-interactive sign-ins were included in the interactive sign-in logs and remained in the interactive sign-in logs after the non-interactive logs became available. Sign-ins using the FIDO2 keys are an example of non-interactive sign-ins that show up in the interactive sign-in logs. At this time, these non-interactive logs are always included in the interactive sign-in log.

You can use the Identity Protection risk detections API to access security detections through Microsoft Graph. This API includes advanced filtering and field selection and standardizes risk detections into one type for easier integration into SIEMs and other data collection tools.

You can troubleshoot Conditional Access policies through all sign-in logs. Review the Conditional Access status and dive into the details of the policies that applied to the sign-in and the result for each policy.

To get started:

• Sign in to the Microsoft Entra admin center.
• Browse to Identity > Monitoring & health > Sign-in logs.
• Select the sign-in that you want to troubleshoot.
• Select the Conditional Access tab to view all the policies that impacted the sign-in and the result for each policy.

Conditional Access status can have the following values:

• Not Applied: There was no Conditional Access policy with the user and app in scope.
• Success: There was a Conditional Access policy with the user and app in scope and Conditional Access policies were successfully satisfied.
• Failure: The sign-in satisfied the user and application condition of at least one Conditional Access policy and grant controls are either not satisfied or set to block access.

A Conditional Access policy can have the following results:

• Success: The policy was successfully satisfied.
• Failure: The policy wasn't satisfied.
• Not applied: The policy conditions might not have been met.
• Not enabled: The policy might be in a disabled state.

The policy name in the sign-in log is based on the Conditional Access policy name at the time of the sign-in. The name can be inconsistent with the policy name in Conditional Access if you updated the policy name after the sign-in.

Currently the sign-in log might not show accurate results for Exchange ActiveSync scenarios when Conditional Access is applied. There can be cases when the sign-in result in the report shows a successful sign-in, but the sign-in actually failed due to a policy.

Conditional Access policies don't apply to Windows Sign-in or Windows Hello for Business. Conditional Access policies protect sign-in attempts to cloud resources, not the Windows sign-in process.

Look up the API reference to see how you can use the APIs to access activity logs. This endpoint has two reports (Audit and Sign-ins) which provide all the data you got in the old API endpoint. This new endpoint also has a sign-ins report with the Microsoft Entra ID P1 or P2 license that you can use to get app usage, device usage, and user sign-in information.

You can use the Identity Protection risk detections API to access security detections through Microsoft Graph. This new format gives greater flexibility in how you can query data. The format provides advanced filtering, field selection, and standardizes risk detections into one type for easier integration into SIEMs and other data collection tools. Because the data is in a different format, you can't substitute a new query for your old queries. However, the new API uses Microsoft Graph, which is the Microsoft standard for such APIs as Microsoft 365 or Microsoft Entra ID. So the work required can either extend your current Microsoft Graph investments or help you begin your transition to this new standard platform.

You might need to sign in to Microsoft Graph separately from the Microsoft Entra admin center. Select your profile icon on the upper-right corner and sign in to the right directory. You might be trying to run a query that you don't have permissions for. Select Modify Permissions and select the Consent button. Follow the sign-in prompts.

Every time a token is used to call a Microsoft Graph endpoint, the MicrosoftGraphActivityLogs are updated with that call. Some of those calls are first-party, app-only calls, which aren't published to the Service Principal sign-in logs. When a MicrosoftGraphActivityLogs shows a uniqueTokenIdentifier that you can't locate in the sign-in logs, the token identifier is referencing a first-party app-only token.

If the service detects activity related to that recommendation for something marked as "completed" it changes automatically back to "active."