1.5 Authentication and Permissions

Managed identity for Microsoft APIs

Managed identity solves the credential management problem. Instead of creating a service account with a password that expires, embedding a client secret that leaks, or hardcoding an API key that appears in the Logic App definition, you enable a system-assigned identity on the Logic App and Azure handles credential issuance, rotation, and revocation automatically.

When your playbook calls Microsoft Graph to query a user's risk level, the HTTP action authenticates using the managed identity token. Azure intercepts the request, obtains an OAuth token for the identity, attaches it to the API call, and the Graph API validates the token against the identity's granted permissions. The entire flow happens without credentials appearing anywhere. No secrets in the Logic App definition. No credentials in the run history. No keys in version control.

Enabling managed identity. The Create playbook wizard in the Defender portal enables a system-assigned managed identity by default when you create a Consumption Logic App with a Sentinel trigger. If you created the Logic App outside the wizard, navigate to Logic App → Settings → Identity → System assigned → Status: On → Save. Azure creates the identity and shows the Object ID. You need this Object ID for permission grants.

Granting Azure RBAC roles. For Sentinel and Log Analytics operations, the managed identity needs RBAC roles at the workspace level. These are granted in the Azure portal because they follow the standard Azure role assignment model.

Enrichment playbooks need two workspace roles: Microsoft Sentinel Responder (read incidents, add comments, change properties, update watchlists) and Log Analytics Reader (run KQL queries against the workspace). These two roles together provide the minimum access for Tier 1 enrichment operations. Do not grant Sentinel Contributor, which allows modifying analytics rules and automation rules in addition to incident operations. Containment playbooks built in later modules need additional roles on specific resources (MDE for device isolation, Entra for session revocation), which are granted when those playbooks are built.

Granting Microsoft Graph API permissions. This is where most builders get stuck. The Azure portal does not support granting application permissions to managed identities directly. You cannot navigate to the Entra admin center and add Graph API permissions to a managed identity the same way you would for an app registration. You must use PowerShell with the Microsoft Graph module.

# Connect with admin permissions (requires AppRoleAssignment.ReadWrite.All)
Connect-MgGraph -Scopes "AppRoleAssignment.ReadWrite.All","Application.Read.All"
# Get the managed identity's service principal
$ManagedIdentity = Get-MgServicePrincipal -Filter "displayName eq 'SA-Playbook-Enrichment-AiTM'"
# Get the Microsoft Graph service principal (resource app)
$GraphSP = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"
# Find the specific permission: IdentityRiskyUser.Read.All
$RiskyUserRole = $GraphSP.AppRoles | Where-Object { $_.Value -eq "IdentityRiskyUser.Read.All" }
# Grant the permission
New-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $ManagedIdentity.Id `
    -PrincipalId $ManagedIdentity.Id `
    -ResourceId $GraphSP.Id `
    -AppRoleId $RiskyUserRole.Id
# Grant User.Read.All for user profile enrichment
$UserReadRole = $GraphSP.AppRoles | Where-Object { $_.Value -eq "User.Read.All" }
New-MgServicePrincipalAppRoleAssignment `
    -ServicePrincipalId $ManagedIdentity.Id `
    -PrincipalId $ManagedIdentity.Id `
    -ResourceId $GraphSP.Id `
    -AppRoleId $UserReadRole.Id

The Connect-MgGraph cmdlet authenticates interactively with the Microsoft Graph PowerShell module. The legacy AzureAD module is deprecated and should not be used for new deployments. The -Scopes parameter requests the permissions needed to grant app role assignments. You must sign in as a Global Administrator or a Privileged Role Administrator. The Get-MgServicePrincipal filter finds the Logic App's managed identity by its display name, which matches the Logic App resource name. The New-MgServicePrincipalAppRoleAssignment cmdlet grants the specific application permission to the managed identity. Permissions take effect within minutes. No Logic App restart is required.

Run this script once per playbook. Each playbook gets only the permissions it needs. The enrichment playbook gets IdentityRiskyUser.Read.All and User.Read.All. A containment playbook built in a later module gets User.RevokeSessions.All. A Defender for Endpoint playbook gets Machine.Isolate. Never pre-grant permissions for playbook features you have not built yet.

The Sentinel service account

The Sentinel service account is separate from the managed identity. The managed identity authenticates the playbook's API calls. The Sentinel service account authenticates the automation rule's invocation of the playbook. Both must be configured.

The Sentinel service account needs the Microsoft Sentinel Automation Contributor role on the resource group where the playbook resides. Without this role, the automation rule fires and selects "Run playbook" as its action, but the playbook never executes. The failure is often silent: the automation rule's run history shows "succeeded" because the rule itself executed its actions, but the playbook invocation is a separate operation that fails without a visible error in the rule's history.

Navigate to the playbook's resource group → Access control (IAM) → Add role assignment → Microsoft Sentinel Automation Contributor → Under "Assign access to," select User, group, or service principal → Search for "Microsoft Sentinel Automation" → Select the Sentinel service principal → Save. This is a one-time configuration per resource group. If all your playbooks are in the same resource group as the Sentinel workspace (recommended), you grant this role once.

Key Vault for third-party API keys

Third-party APIs like VirusTotal, AbuseIPDB, and Shodan authenticate with API keys. These keys must never appear in Logic App definitions. Anyone with read access to the Logic App (Contributor role on the resource group) can view the full JSON definition, including any hardcoded values. Key Vault solves this by storing secrets outside the Logic App and providing them at runtime via managed identity authentication.

Create an Azure Key Vault in the same resource group as your Logic Apps. Enable the RBAC authorization model (not the legacy access policy model) during creation. The RBAC model integrates with Azure role assignments, which is consistent with how you manage all other permissions in this course. The legacy access policy model is a separate permission system that does not appear in IAM role listings and is harder to audit.

Store each API key as a named secret: "VirusTotal-API-Key," "AbuseIPDB-API-Key." Grant the Logic App's managed identity the Key Vault Secrets User role on the Key Vault. This role allows reading secret values at runtime but not modifying, deleting, or listing all secrets. It is the minimum permission the playbook needs.

In the Logic App, add an "Azure Key Vault - Get secret" action before the HTTP action that calls the third-party API. Select the Key Vault name and the secret name. The action retrieves the secret value at runtime. Reference the output in the subsequent HTTP action's authorization header: Authorization: @{body('Get_secret')?['value']}. The API key is read fresh from Key Vault each time the playbook runs. When you rotate the key (generate a new one in VirusTotal, update the Key Vault secret), the Logic App uses the new key on the next execution with no playbook modification. This decoupling between the key value and the playbook definition means that key rotation is a Key Vault operation, never a Logic App code change.

The least-privilege permission matrix

Every permission beyond the minimum required is attack surface. An enrichment playbook with Directory.ReadWrite.All (granted "just in case") gives a compromised managed identity the ability to create admin accounts, modify group memberships, and change Conditional Access policies. An enrichment playbook with User.Read.All limits the compromise to reading user properties: visibility without modification capability.

The permission matrix is the specification. When you build each playbook in this course, the section specifies the exact permissions required. Do not add permissions that are not listed. If a future playbook enhancement requires a new permission, grant it explicitly at that time using the PowerShell script from earlier in this section. Pre-granting permissions for features you have not built creates unnecessary attack surface and fails security audit reviews.

Quarterly permission audit

Every 90 days, review all managed identity permissions. The audit compares granted permissions against the actions the playbook currently uses. If a permission was granted during development but the corresponding action was removed in a later revision, remove the permission. The Microsoft Graph PowerShell module provides the commands for this audit.

Run Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id for each Logic App to list its current Graph API permissions. Cross-reference each granted permission against the playbook's HTTP actions that call the Graph API. If a permission does not map to any current action, remove it with Remove-MgServicePrincipalAppRoleAssignment. This audit also catches permissions that were granted to the wrong managed identity, a common error when copying permission scripts between playbooks without updating the service principal filter.

The audit should also review OAuth connections. Navigate to each Logic App in the Azure portal and check the API Connections section. Each connection shows the user account that authorized it. If any connection is tied to a personal analyst account rather than the service account, migrate it. If any connection shows a warning or error status, the authorizing account may have been disabled, changed its password, or had its MFA configuration modified. Re-authorize the connection using the service account.

Document the audit results. Record which Logic App has which permissions, which connections were re-authorized, and which permissions were removed. This documentation becomes the formal baseline for the next quarterly review. The governance framework from Section 0.9 includes the permission audit as a required quarterly activity.