Haivng null values in SPN and UPN ID log data adls

Hello @ Danish Ahmed Khan,

Thank you for reaching out to Microsoft Q&A.
When you see ADLS “Read” entries that show dataset names and read counts but SPN_ID and UPN_ID as null, it usually means the operation wasn’t authenticated by a user or service principal that Azure AD can surface in the log. A few common culprits:

• SAS tokens or storage account keys – Reads done via a Shared Access Signature or account key don’t go through Azure AD, so there is no SPN or UPN to stamp on the log.

• Internal or system-level processes – Some background services (e.g., internal metadata crawlers, platform health checks, Purview scans, etc.) use built-in service accounts that don’t appear as customer-facing SPNs in diagnostic logs.

• Anonymous/guest access – If the container or file system allows anonymous reads, those requests likewise won’t have an Azure AD identity.

What you’re seeing is expected behavior: if there’s no true Azure AD principal on the call, SPN_ID and UPN_ID come through as null. If you need visibility into who (or what) is hitting your data, you can:

1. Switch to Azure AD–authenticated access only (disable anonymous/SAS where possible).
2. Use Azure RBAC or service principals/managed identities for all data reads.
3. Correlate with other logs (e.g., Azure AD sign-in logs or your own application logs).

If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment".

Diagnostic logs for Azure Storage (including ADLS) can legitimately contain null values for identity-related fields such as SPN/UPN when the request isn’t authenticated with Microsoft Entra ID.

From the monitoring guidance:

• When a request is authenticated with Microsoft Entra ID (OAuth), the RequesterObjectId and sometimes the UPN are populated and can be used to identify the security principal.
• For Shared Key and SAS authentication, there is no identity information in the token itself. The documentation explicitly states that Shared Key and SAS “provide no means of auditing individual identities.”
• For SAS, logs instead expose an AuthenticationHash (SHA-256 hash of the SAS signature) so that activity can be correlated to a particular SAS token if a separate mapping is maintained.

Therefore:

1. Records with dataset, read count, and date but null SPN/UPN typically correspond to:
   • Requests authenticated via SAS tokens.
   • Requests authenticated via Shared Key.
   • Certain non-user or internal system operations where no Entra principal is attached to the call.
2. This behavior is expected: the platform logs the operation itself (what was accessed, when, and how) but cannot populate SPN/UPN because those values don’t exist for these authentication types.
3. To audit by identity instead of seeing nulls, the recommended approach is to move to Microsoft Entra ID–based access and to prevent Shared Key and SAS where possible.
4. If SAS must be used, correlate activity by:
   • Computing the SHA-256 hash of each SAS signature and
   • Matching it with the AuthenticationHash in the logs, maintaining a mapping of which SAS token was issued to which user or system.

So the null SPN/UPN values in the logs are most likely due to SAS or Shared Key usage (or similar non-OAuth access), not a logging issue.

References:

• Best practices for monitoring Azure Blob Storage