Investigate authentication issues using sign-in logs

  • 8 minutes

Microsoft 365 administrators and IT administrators are responsible for knowing how their IT environments are performing. The information about their systems' health enables them to assess whether and how they must respond to potential issues.

To support this goal, the Microsoft Entra admin center provides administrators with access to three activity logs:

  • Sign-in logs. Provides information about sign-ins and how users use the organization's resources.
  • Audit logs. Provides information about changes applied to the company's tenant. For example, users and group management, or updates applied to the tenant’s resources.
  • Provisioning logs. Provides a list of activities performed by the provisioning service. For example, the creation of a group in ServiceNow, or a user imported from Workday.

This unit provides an overview of the sign-in log. For more information on audit logs and provisioning logs, see:

Overview of the Sign-in log

Microsoft Entra ID logs all user sign-ins into an Azure tenant, which includes your internal apps and resources. As an IT administrator, it's important that you understand the values tracked in the log files so that you can correctly interpret them. Reviewing sign-in errors and patterns provides valuable insight into how your users access applications and services. The sign-in logs provided by Microsoft Entra ID are a powerful type of activity log that you can analyze. The preview view of the sign-in logs includes interactive and non-interactive user sign-ins as well as service principal and managed identity sign-ins. You can still view the classic sign-in logs, which only include interactive sign-ins.

Organizations can use the sign-in logs to answer questions such as:

  • How many users signed into a particular application this week?
  • How many failed sign-in attempts occurred in the last 24 hours?
  • Are users signing in from specific browsers or operating systems?
  • Which of the company's Azure resources do managed identities and service principals access?

You can also describe the activity associated with a sign-in request by identifying the following details:

  • Who – The identity (User) performing the sign-in.
  • How – The client (Application) used for the sign-in.
  • What – The target (Resource) accessed by the identity.

There are four types of logs in the Sign-in events page:

  • Interactive user sign-ins
  • Non-interactive user sign-ins
  • Service principal sign-ins
  • Managed identity sign-ins

The classic sign-in logs only include interactive user sign-ins.

Note

Entries in the sign-in logs are system generated. Administrators can't change or delete them.

Interactive user sign-ins

Users perform Interactive sign-ins. This type of sign-in event provides an authentication factor to Microsoft Entra ID that can also interact with a helper app, such as the Microsoft Authenticator app. Users can provide passwords, responses to MFA challenges, biometric factors, or QR codes to Microsoft Entra ID or to a helper app. This log also includes federated sign-ins from identity providers that are federated to Microsoft Entra ID.

Screenshot of the Microsoft Entra sign-in events page showing interactive user sign-ins highlighted.

Examples of the types of interactive user sign-in events that are displayed in this log include:

  • A user provides username and password in the Microsoft Entra sign-in screen.
  • A user passes an SMS MFA challenge.
  • A user provides a biometric gesture to unlock their Windows PC with Windows Hello for Business.
  • A user is federated to Microsoft Entra ID with an AD FS SAML assertion.

In addition to the default fields, the interactive sign-in log also shows:

  • The sign-in location
  • Whether Conditional Access applies

Administrators should be aware of the known limitations with the interactive user sign-in log, including:

  • Non-interactive sign-ins on the interactive sign-in logs. Previously, the interactive user sign-in log included some non-interactive sign-ins from Microsoft Exchange clients for better visibility. This increased visibility was necessary before Microsoft introduced the non-interactive user sign-in logs in November 2020. However, it's important to note that the system might still mark some non-interactive sign-ins, such as those using FIDO2 keys, as interactive. If this situation occurs, it's due to how Microsoft set up the log before it introduced separate non-interactive logs. These sign-ins might display interactive details like client credential type and browser information, even though the sign-ins are technically non-interactive.
  • Passthrough sign-ins. Microsoft Entra ID issues tokens for authentication and authorization. Consider the scenario where a user who signed into the Contoso tenant tries to access resources in the Fabrikam tenant, where they don't have access. The system issues a no-authorization token called a passthrough token to the Fabrikam tenant. The passthrough token doesn't allow the user to access any resources. When you review the logs for this situation, the sign-in logs for the home tenant (in this scenario, Contoso) don't show a sign-in attempt because the system didn't evaluate the token against the home tenant's policies. The system only used the sign-in token to display the appropriate failure message. As a result, sign-in attempts aren't recorded for this scenario in the home tenant logs.
  • First-party, app-only service principal sign-ins. The service principal sign-in logs don't include first-party, app-only sign-in activity. This type of activity happens when first-party apps get tokens for an internal Microsoft job where there's no direction or context from a user. We exclude these logs so you're not paying for logs related to internal Microsoft tokens within your tenant. You can identify Microsoft Graph events that don't correlate to a service principal sign-in if you're routing MicrosoftGraphActivityLogs with SignInLogs to the same Log Analytics workspace. This integration allows you to cross reference the token issued for the Microsoft Graph API call with the sign-in activity. The UniqueTokenIdentifier for sign-in logs and the SignInActivityId in the Microsoft Graph activity logs would be missing from the service principal sign-in logs.

Non-interactive user sign-ins

A non-interactive sign-in occurs when a client app or OS component performs a delegated sign-in on behalf of a user. As such, they don't require the user to provide an authentication factor. Instead, Microsoft Entra ID recognizes when the user's token must be refreshed and does so behind the scenes, without interrupting the user's session. In general, the user perceives these sign-ins as happening in the background.

Screenshot of the Microsoft Entra sign-in events page showing non-interactive user sign-ins highlighted.

Examples of the types of non-interactive user sign-in events that are displayed in this log include:

  • A client app uses an OAuth 2.0 refresh token to get an access token.
  • A client uses an OAuth 2.0 authorization code to get an access token and refresh token.
  • A user performs single sign-on (SSO) to a web or Windows app on a Microsoft Entra joined PC (without providing an authentication factor or interacting with a Microsoft Entra prompt).
  • A user signs in to a second Microsoft Office app while they have a session on a mobile device using FOCI (Family of Client IDs).

In addition to the default fields, the non-interactive sign-in log also shows:

  • Resource ID
  • Number of grouped sign-ins

You can't customize the fields shown in this report.

To make it easier to digest the data, the system groups non-interactive sign-in events. Clients often create many non-interactive sign-ins on behalf of the same user in a short time period. The non-interactive sign-ins share the same characteristics except for the time the sign-in was attempted. For example, a client receives an access token once per hour on behalf of a user. If the state of the user or client doesn't change, the IP address, resource, and all other information is the same for each access token request. The only state that does change is the date and time of the sign-in.

You might notice situations where Microsoft Entra ID logs multiple sign-ins that are identical other than time and date. Those sign-ins are from the same entity and are aggregated into a single row. A row with multiple identical sign-ins (except for date and time issued) has a value greater than one in the # sign-ins column. These aggregated sign-ins can also appear to have the same time stamps. The Time aggregate filter can set to 1 hour, 6 hours, or 24 hours. You can expand the row to see all the different sign-ins and their different time stamps.

Sign-ins are aggregated in the non-interactive users when the following data matches:

  • Application
  • User
  • IP address
  • Status
  • Resource ID

Note

The IP address of non-interactive sign-ins performed by confidential clients doesn't match the actual source IP of where the refresh token request is coming from. Instead, it shows the original IP used for the original token issuance.

Service principal sign-ins

Unlike interactive and non-interactive user sign-ins, service principal sign-ins don't involve a user. Instead, these sign-ins are by a nonuser account, such as apps or service principals (except managed identity sign-in, which are in included only in the managed identity sign-in log). In these sign-ins, the app or service provides its own credential, such as a certificate or app secret to authenticate or access resources.

Screenshot of the Microsoft Entra sign-in events page showing service principal user sign-ins highlighted.

Examples of the types of service principal sign-in events that are displayed in this log include:

  • A service principal uses a certificate to authenticate and access Microsoft Graph.
  • An application uses a client secret to authenticate in the OAuth Client Credentials flow.

You can't customize the fields shown in this report.

To make it easier to digest the data in the service principal sign-in logs, the system groups service principal sign-in events. Sign-ins from the same entity under the same conditions are aggregated into a single row. You can expand the row to see all the different sign-ins and their different time stamps. Sign-ins are aggregated in the service principal report when the following data matches:

  • Service principal name or ID
  • Status
  • IP address
  • Resource name or ID

Managed identity sign-ins

Managed identities for Azure resources sign-ins are sign-ins performed by resources that have their secrets managed by Azure to simplify credential management. A VM with managed credentials uses Microsoft Entra ID to get an access token.

Screenshot of the Microsoft Entra sign-in events page showing managed identity user sign-ins highlighted.

You can't customize the fields shown in this report.

To make it easier to digest the data, the system groups managed identities for Azure resources sign-in logs. Sign-ins from the same entity are aggregated into a single row. You can expand the row to see all the different sign-ins and their different time stamps. Sign-ins are aggregated in the managed identities report when all of the following data matches:

  • Managed identity name or ID
  • Status
  • Resource name or ID

Select an item in the list view to display all sign-ins grouped under a node. Select a grouped item to see all details of the sign-in.