Frequently asked questions around Azure Active Directory reports

This article includes answers to frequently asked questions about Azure Active Directory (Azure AD) reporting. For more information, see Azure Active Directory reporting.

Getting started

How do I get a premium license?

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

How soon should I see activities data after getting a premium license?

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 will take up to three days for the data to show up in the reports.

Can I see last month's data after getting an Azure AD premium license?

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.

I currently use the https://graph.windows.net/<tenant-name>/reports/ endpoint APIs to pull Azure AD security reports (specific types of detections, such as leaked credentials or sign-ins from anonymous IP addresses) into our reporting systems programmatically. What should I switch to?

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.

Activity logs

Do I need to be a Global Administrator to see the activity logs in the Azure portal or to get data through the API?

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.

Can I get Microsoft 365 activity log information through the Azure portal?

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.

Which APIs do I use to get information about Microsoft 365 Activity logs?

The APIs for Microsoft 365 are described in the Microsoft 365 Management APIs article.

How many records I can download from the Azure portal?

You can 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.

How long does Azure AD store activity logs? What is the data retention?

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.

Sign-in logs

What data is included in the CSV file I can download from the Azure AD sign-in logs?

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.

I see .XXX in part of the IP address from a user in my sign-in logs. Why is that happening?

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.

I selected the **Load More** button in the Azure portal sign-in logs, but no more results appeared. Why is that happening?

This is a known issue with a fix on the way from Azure AD engineering, where if during a 24-hour period in the results of your query has no sign-ins, no sign-ins will appear when you select Load More. If your tenant is impacted by this issue, select the Load More button multiple times. You can also work around this issue by increasing the scope of your query so that each 24-hour period in your response has sign-ins.

I see "PII Removed" in the Device Details of a user in my sign-in logs. Why is that happening?

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.

I clicked the Load More button in the Azure portal Sign-in logs, but no more results appeared. Why is that happening?

This is a known issue with a fix on the way from Azure AD engineering where if a 24h period in the results of your query has no sign-ins, no sign-ins will appear when you click Load More. If your tenant is impacted by this issue, you can load more results by clicking the Load More button multiple times. You can also work around this issue by increasing the scope of your query so that each 24h period in your response has sign-ins.

I see duplicate sign-in entries / multiple sign-in events per requestID. Why is that happening?

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.

Why do my non-interactive sign-ins appear to have the same time stamp?

Non-interactive sign-ins can trigger a large volume of events every hour, so they are 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 will appear to show the sign-ins at the same time. Each of these grouped rows can be expanded to view the exact time stamp.

I am seeing User IDs in the username field of my sign-ins log. Why is this happening?

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 will say passwordless.

Conditional Access

What Conditional Access (CA) details can I see in the sign-in logs?

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 got to Azure AD > 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.

What are all possible values for the Conditional Access status?

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.

What are all possible values for the Conditional Access policy result?

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 doesn't match the policy name in Conditional Access. Why?

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.

My sign-in was blocked due to a Conditional Access policy, but the sign-ins log shows that the sign-in succeeded. Why?

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.

Microsoft Graph APIs

I currently use the https://graph.windows.net/<tenant-name>/reports/ endpoint APIs to pull Azure AD audit and integrated application usage reports into our reporting systems programmatically. What should I switch to?

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.

I currently use the https://graph.windows.net/<tenant-name>/reports/ endpoint APIs to pull Azure AD security reports (specific types of detections, such as leaked credentials or sign-ins from anonymous IP addresses) into our reporting systems programmatically. What should I switch to?

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.

I keep getting permissions errors when running queries. I thought I had the appropriate role.

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.