Unable to fetch Service Principal and Managed Identity sign-in logs using Microsoft Graph (400 errors & missing data)

Question

Trying PowerShell automation to generate an Azure App Registration usage report, including:

• Interactive sign-ins
• Non-interactive sign-ins
• Service Principal (app-only) sign-ins
• Managed Identity sign-ins

What Works

• Using GET /auditLogs/signIns
• Able to retrieve:
  • Interactive (isInteractive = true)
  • Non-interactive (isInteractive = false)

Issue

I’m unable to get Service Principal (SP) and Managed Identity (MI) sign-ins:

servicePrincipalId is not reliable in signIns

This endpoint fails even for basic calls:

GET /v1.0/auditLogs/servicePrincipalSignIns?$top=10

and also in beta:

GET /beta/auditLogs/servicePrincipalSignIns?$top=10

Error:

HTTP 400 Bad Request

---

Question

What is the correct way to fetch SP and MI sign-in activity?

Is servicePrincipalSignIns supported in v1.0?

Do we need additional permissions beyond:

AuditLog.Read.All

  Directory.Read.All
  

• Is there a better API (e.g. servicePrincipalSignInActivity)?

  Issue

  I’m unable to get Service Principal (SP) and Managed Identity (MI) sign-ins:
  1. servicePrincipalId is not reliable in signIns
  2. This endpoint fails even for basic calls:

    GET /v1.0/auditLogs/servicePrincipalSignIns?$top=10
  

  and also in beta:

    GET /beta/auditLogs/servicePrincipalSignIns?$top=10
  

  Error:

    HTTP 400 Bad Request
  

  Question

  What is the correct way to fetch SP and MI sign-in activity?
  • Is servicePrincipalSignIns supported in v1.0?
  • Do we need additional permissions beyond:
    • AuditLog.Read.All
    • Directory.Read.All
  • Is there a better API (e.g. servicePrincipalSignInActivity)?

Using PowerShell:

Connect-MgGraph -Identity

Any guidance would help. Thanks!

Answer 1

Service principal (SP) and managed identity (MI) sign-ins are exposed through the same /auditLogs/signIns API as user sign-ins. The correct way to retrieve them is to filter by sign-in event type, not by a separate servicePrincipalSignIns collection.

1. Correct API for SP and MI sign-ins

Use auditLogs/signIns and filter on signInEventTypes:

• Service principal sign-ins:

GET https://graph.microsoft.com/beta/auditLogs/signIns?
  $filter=(createdDateTime ge 2024-01-13T14:13:32Z and createdDateTime le 2024-01-14T17:43:26Z)
    and signInEventTypes/any(t: t eq 'servicePrincipal')

• Managed identity sign-ins:

GET https://graph.microsoft.com/beta/auditLogs/signIns?
  $filter=(createdDateTime ge 2024-01-13T14:13:32Z and createdDateTime le 2024-01-14T17:43:26Z)
    and signInEventTypes/any(t: t eq 'managedIdentity')

These patterns are documented for analyzing activity logs with Microsoft Graph and are the supported way to get SP and MI sign-ins.

For interactive vs non-interactive user sign-ins, use:

• signInEventTypes/any(t: t eq 'interactiveUser')
• signInEventTypes/any(t: t eq 'nonInteractiveUser')

The possible values are:

• interactiveUser
• nonInteractiveUser
• servicePrincipal
• managedIdentity
• unknownFutureValue

2. About servicePrincipalSignIns and v1.0

From the provided context, only auditLogs/signIns is documented for sign-in logs. The examples and guidance for SP and MI sign-ins all use auditLogs/signIns with signInEventTypes filters. There is no documented auditLogs/servicePrincipalSignIns collection in the referenced material, which explains the 400 errors when calling that path.

3. Permissions

For sign-in logs via Microsoft Graph PowerShell and REST:

• AuditLog.Read.All
• Directory.Read.All

are listed as the required permissions for Get-MgAuditLogSignIn / Get-MgBetaAuditLogSignIn, which read from auditLogs/signIns.

Example (PowerShell, including SP and MI sign-ins via beta):

Import-Module Microsoft.Graph.Beta.Reports
Connect-MgGraph -Identity

# Service principal sign-ins
Get-MgBetaAuditLogSignIn -Filter "signInEventTypes/any(t: t eq 'servicePrincipal')" -Top 50

# Managed identity sign-ins
Get-MgBetaAuditLogSignIn -Filter "signInEventTypes/any(t: t eq 'managedIdentity')" -Top 50

4. servicePrincipalId reliability

For some sign-ins, the service principal ID can be 00000000-0000-0000-0000-000000000000. This indicates there is no service principal for the client or resource application in that authentication instance. This is allowed only for a limited set of apps.

To find such cases:

• Missing client SP:

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

• Missing resource SP:

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

This behavior is expected for specific Microsoft and non-Microsoft apps and explains why servicePrincipalId alone is not always reliable.

5. servicePrincipalSignInActivity vs sign-in logs

servicePrincipalSignInActivity (in /beta/reports/servicePrincipalSignInActivities/{id}) returns last sign-in information per service principal, not the full sign-in log stream. It is useful for “when did this app last sign in?” but not for detailed per-event reporting across all sign-ins.

For a comprehensive usage report (interactive, non-interactive, SP, MI), use:

• /auditLogs/signIns with signInEventTypes filters (v1.0 or beta as required)
• Optionally, servicePrincipalSignInActivity for summary/last-sign-in per SP.

---

References:

• How to analyze activity logs with Microsoft Graph
• Learn about the sign-in log activity details
• Frequently asked questions around Microsoft Entra monitoring and health
• What are Microsoft Entra sign-in logs?
• Microsoft Graph PowerShell cmdlets for Microsoft Entra monitoring and health
• Get-MgAuditLogSignIn
• Get-MgBetaAuditLogSignIn
• Get servicePrincipalSignInActivity