Log Analytics workspace access denied for managed identity in monitoring pipeline

Cloud Platforms Microsoft Azure
, , , , , , , ,
1

Our automated monitoring pipeline is failing to ingest custom logs into Log Analytics workspace. The Azure Function uses a system-assigned managed identity to write logs, but we’re getting access denied errors since yesterday:


Error: 403 Forbidden
The client does not have authorization
WorkspaceId: xxx-xxx-xxx

The managed identity was working fine for weeks. I checked the IAM blade on the Log Analytics workspace and the managed identity is listed with “Log Analytics Contributor” role. The function app itself works fine, it’s just the Log Analytics write operation that fails. Could this be a managed identity RBAC issue or something with Log Analytics permissions specifically?

2

Another thing to check: is your Function App’s managed identity actually enabled? Sometimes during deployments or infrastructure updates, the system-assigned identity can get disabled accidentally. Go to your Function App > Identity and verify the system-assigned managed identity is still “On”. If it got toggled off and back on, a new identity was created with a different object ID, and your old role assignments wouldn’t apply anymore.

3

The role assignment has been there for over a month, so it’s not a propagation issue. I double-checked the workspace ID - it matches what’s in the portal. The weird thing is nothing changed on our end. Could Azure have made changes to Log Analytics permissions or managed identity authentication?

4

Check the specific API endpoint you’re calling. Log Analytics has different APIs (legacy HTTP Data Collector API vs newer DCR-based ingestion), and they have different permission requirements. The legacy API requires workspace keys, while DCR-based ingestion uses Azure AD authentication with specific RBAC roles.

5

I can help you troubleshoot this systematically. The 403 error indicates an authorization problem, and there are several layers to check:

1. Managed Identity RBAC Verification First, confirm the managed identity is correctly assigned and active:


az functionapp identity show \
  --name <function-app-name> \
  --resource-group <rg-name>

Note the principalId. Then verify role assignments:


az role assignment list \
  --assignee <principal-id> \
  --scope <log-analytics-workspace-resource-id>

For custom log ingestion, “Log Analytics Contributor” is actually insufficient. You need “Monitoring Metrics Publisher” role or a custom role with Microsoft.Insights/Logs/Write permission. The Contributor role provides management plane access but doesn’t grant data plane write permissions for log ingestion.

2. Log Analytics Permissions and API Method Determine which ingestion method you’re using:

  • Legacy HTTP Data Collector API: Requires workspace ID and shared key (doesn’t use managed identity at all)
  • Data Collection Rules (DCR): Uses Azure AD authentication with managed identity

If you’re using DCR-based ingestion (the modern approach), the managed identity needs:

  • “Monitoring Metrics Publisher” role on the DCR resource
  • Proper DCR configuration with the workspace as destination
  • The DCR endpoint URL (not the workspace URL)

Verify your DCR configuration and ensure the managed identity has permissions on the DCR itself, not just the workspace.

3. Activity Log Review for Changes Check Activity Logs for the workspace:


az monitor activity-log list \
  --resource-id <workspace-resource-id> \
  --start-time <yesterday> \
  --query "[?contains(operationName.value, 'roleAssignments')]"

Look for:

  • Role assignment deletions or modifications
  • Workspace configuration changes
  • Access control policy updates
  • Any failed authentication attempts in the logs

Resolution Steps

  1. If using DCR-based ingestion, add the correct role:

az role assignment create \
  --assignee <managed-identity-principal-id> \
  --role "Monitoring Metrics Publisher" \
  --scope <dcr-resource-id>

  1. If using legacy API, either:

    • Switch to DCR-based ingestion (recommended)
    • Use workspace shared keys stored in Key Vault (less secure)

  2. Verify the Function App code is using the correct endpoint URL:

    • DCR: `https://.ingest.monitor.azure.com
    • Legacy: `https://.ods.opinsights.azure.com

  3. Test authentication separately:

    • Use Azure CLI or PowerShell to test if the managed identity can authenticate to the workspace
    • Check for any Conditional Access policies blocking service principal authentication

Common Gotcha: If your organization recently enabled Azure Policy for Log Analytics or deployed security baselines, there might be new policies preventing managed identity access. Check Azure Policy compliance for your workspace resource.

After making RBAC changes, wait 5-10 minutes for propagation, then test your function. If still failing, capture the detailed error response body - it often contains specific permission requirements that are missing.

6

403 errors with managed identities usually mean either the role assignment is missing/wrong, or there’s a propagation delay. Even though you see the role in IAM, check when it was assigned. If it was recent (within the last hour), Azure RBAC can take up to 30 minutes to propagate fully across regions.

Also verify you’re using the correct workspace ID in your function code. Sometimes people confuse the workspace ID with the resource ID, and that can cause auth failures.

7

I’ve seen this before. For programmatic log ingestion, you need the managed identity to have permissions at the data collection endpoint level, not just the workspace. If you’re using the new Data Collection Rules (DCR) for custom logs, the managed identity needs specific permissions on the DCR itself. Check if your organization recently migrated to DCR-based ingestion - that would explain why it suddenly stopped working.