Title: Microsoft Sentinel – Logic Apps Playbook Permissions Update Fails: Service Principal Not Found

Do not recreate the Logic Apps or manually create a service principal for [GUID]; because the documented Sentinel identity already has the required resource-group role and the Defender portal is attempting to manage a different, undocumented application ID, open a Microsoft support request for tenant/portal permission-record repair.

What the evidence establishes

• Microsoft Sentinel’s service account requires Microsoft Sentinel Automation Contributor on the resource group containing the playbooks. The documented enterprise application is Azure Security Insights. Your assignment to its object ID at HighTempEcom therefore matches the documented permission model.^1^
• Automation Contributor is still managed through Azure RBAC, not Microsoft Defender unified RBAC. Moving Sentinel into the Defender portal does not introduce a documented replacement identity for this role.^2^
• The available Microsoft documentation does not identify [GUID] as a Microsoft Sentinel application ID. It therefore cannot be safely classified as required, obsolete, or Microsoft-owned from the GUID alone.
• Microsoft first-party applications do not always have local service-principal objects in every tenant. Their ownership should be verified under Enterprise applications → Application type: Microsoft Applications, but absence alone does not prove that an administrator should instantiate one.^3^

Since you already removed and restored the correct assignment without changing the warning, repeating that operation is unlikely to repair the portal’s reference to the other application ID.

Open a support request without disrupting automation

Create an Azure support request under Microsoft Sentinel → Automation and playbooks or Assigning permissions and using RBAC. Owner, Contributor, Support Request Contributor, or an equivalent custom role can create the request.^4^

Include:

1. Tenant ID, subscription ID, and Sentinel workspace resource ID.
2. Resource group HighTempEcom.
3. Exact UTC timestamps and screenshots for:
   • Failed to update Logic Apps permissions: 1
   • Service principal not found for application ID: [GUID]
4. Output showing both the missing GUID and the existing Azure Security Insights service principal:

      az account show --query "{tenant:tenantId,subscription:id}" -o json
      az ad sp show --id [GUID]
      az ad sp show --id [GUID]
   

5. The resource-group role assignment for Azure Security Insights:

      az role assignment list \
        --scope "/subscriptions/[Subscription ID] ID]/resourceGroups/[Resource Group] Group]" \
        --assignee-object-id "<Azure-Security-Insights-object-id>" \
        --include-inherited -o table
   

6. State that playbook runs succeed and that deleting/reassigning the documented role did not clear the warning.
7. Ask support to:
   • identify the owner and purpose of application ID [GUID];
   • inspect the Sentinel playbook-permission record for a stale identity reference;
   • reprovision the Microsoft-managed identity or remove the stale record through a supported backend operation;
   • confirm whether this is a Defender portal defect.

Avoid posting tenant, subscription, or object IDs publicly.

Conditional provisioning—only after Microsoft confirms the GUID

Microsoft Entra supports creating a tenant-local enterprise application from a confirmed multitenant application ID using az ad sp create. This requires Cloud Application Administrator or Application Administrator.^5^

However, do not run the following unless Microsoft Support confirms that this exact GUID is the required first-party Sentinel application and explicitly directs tenant provisioning:

az login --tenant <tenant-id>
az account show --query tenantId -o tsv
az ad sp create --id [GUID]
az ad sp show --id [GUID]

Creating an enterprise application from an unidentified GUID changes the tenant directory and may instantiate an unrelated application. It also might not repair a stale permission record in the Defender portal.

Continue operating the existing playbooks while the case is investigated. Successful runs indicate that their runtime connections remain functional; the portal warning concerns Sentinel’s resource-group permission-management state, which is separate from each Logic App’s connector authentication.^6^

References

1. Automate and run Microsoft Sentinel playbooks
2. Map existing RBAC permissions to Microsoft Defender unified RBAC permissions
3. Verify first-party Microsoft applications in sign-in reports
4. Connect Microsoft Sentinel to the Microsoft Defender portal
5. Create an enterprise application from a multitenant application (azure-cli)
6. Authenticate playbooks to Microsoft Sentinel