Frequently asked questions around Azure Active Directory reports

See Getting started with Azure Active Directory Premium to upgrade your Azure Active Directory edition.

If you already have activities 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've 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.

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 includes advanced filtering and 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 Azure AD. So the work required can either extend your current Microsoft Graph investments or help you begin your transition to this new standard platform.

No, the least privilege role to view audit and sign-in logs is Reports Reader. Other roles include Security Reader and Security Administrator for the tenant. You can also access the reporting data through the portal or through the API if you're a Global Administrator.

Microsoft 365 and Azure AD 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.

How many logs you can download from the Azure portal is determined by a few factors, including browser memory size, network speeds, and current load on Azure AD Reporting APIs. In general, you can expect to download up to 250,000 records from the Azure portal. To download data sets larger than 250,000 records, use the reporting API to download the data. The specific set of logs you download is determined by the filters active in the Azure portal when you begin the download (for example, filtering to a specific user in the Azure portal will mean your download pulls logs for that specific user).

Depending on your license, Azure AD stores activity logs for between 7 and 30 days. For more information, see Azure Active Directory report retention policies.

The signInActivity resource is used to find inactive users who haven't signed in for some time. It does not update in near real time; you should expect up to 6 hours before the property is updated for a given user. If you need to find the user's last sign-in activity more quickly than that, you can use the Azure AD sign-ins blade to see near real time sign-in activity for all your users.

The CSV includes sign-in logs for your users and service principals. However, data that is represented as a nested array in the MS Graph API for sign-in logs isn't 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.

Azure AD may redact part of an IP address in the sign-in logs to protect user privacy when a user may not belong to the tenant viewing the logs. This action happens in two cases: first, during cross tenant sign ins, such as when a CSP technician signs into a tenant that CSP manages. Second, 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.

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

There are several reasons sign-in entries may 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 will be retried and published again, which may result in duplicates.
• Sign-in events that involve multiple Conditional Access policies may be split into multiple events, which can result in at least two events per sign-in event.

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.

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.

No, in general 90025 errors are resolved by an automatic retry without the user noticing the error. This error can occur when an internal Azure AD subservice hits its retry allowance and doesn't indicate your tenant is being throttled. These errors are usually resolved by Azure AD internally without any user impact. 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", it means that there's no Service Principal for the client application in that instance of authentication. Azure AD no longer issues access tokens without a client Service Principal, except for a few Microsoft and third party applications.

If the Resource Service Principal ID has the value “0000000-0000-0000-0000-000000000000", it means that 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 Azure AD Portal.

• Sign in to the Azure portal and go to Azure Active Directory.
• Navigate to Sign in Logs under Monitoring,
• Select the Service Principal Sign-ins.
• Select an appropriate time frame in the Date field (last 24 hours, 7 days etc.).
• 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 Azure AD app to a set of users article.

You can troubleshoot Conditional Access policies through all sign-ins log. Review the CA 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 Azure portal and go to Azure Active Directory then select Sign-ins log.
• Select the sign-in that you want to troubleshoot.
• Navigate to the Conditional Access tab. Here, you can 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 CA policy with the user and app in scope.
• Success: There was a CA policy with the user and app in scope and CA policies were successfully satisfied.
• Failure: The sign-in satisfied the user and application condition of at least one CA policy and grant controls are either not satisfied or set to block access.

A CA policy can have the following results:

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

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

Currently the sign-ins log may 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 CA policy.

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 Azure AD Premium 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, with advanced filtering, field selection, and more, 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 Azure AD. So the work required can either extend your current Microsoft Graph investments or help you begin your transition to this new standard platform.

You may need to sign in to Microsoft Graph separately from the Azure portal. Select your profile icon on the upper-right corner and sign in to the right directory. You may 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.