Assigning API Permissions to Managed Identities

A step-by-step PowerShell guide for assigning Microsoft Graph permissions to Azure managed identities.

Apr 12, 2025

In one of my previous posts I mentioned that you can assign permissions to a managed identity. In this post I wanted to explain what information you need to achieve this. I can’t take credit the actual code, I got it from one of the links in the resources section at the bottom.

Managed identities simplify authentication in Azure by eliminating the need to manage credentials like passwords or secrets. Because Azure trusts this identity you can use it to access different resources like Defender, Intune or SharePoint but you will need to assign it the necessary API permissions first.

What You’ll Need:

According to Microsoft Graph Test API documentations to grant an app role assignment to a client service principal, you need three identifiers:

principalId: The ID of the client service principal receiving the app role assignment. This could represent an Entra app or a azure resource with a managed identity enabled.
resourceId: The ID of the API (resource service principal) that defines the app role. For example Graph, Defender, ShrePoint etc
appRoleId: The ID of the app role being assigned to the client service principal.

🧩 Step 1: Connect to Microsoft Graph

Connect-MgGraph -DeviceCode -Scopes "AppRoleAssignment.ReadWrite.All",
"Application.Read.All"

Authenticates your session to Microsoft Graph with the right scopes to read and assign app roles.
💡 You’ll be prompted with a device code login.

🧩 Step 2: Find the Managed Identity’s Service Principal

Get-MgServicePrincipal -Filter "startswith(DisplayName, 'func')"

Fetches sthe service principal for your Azure Function (or other resource) by partial name.

I normally use a naming convention (For example func-navigator-prod-001.azurewebsites.net for Azure functions or aa-mktgsharepoint-prod-001 for automation accounts) when naming azure resources and the corresponding service principal will use that name, therefore making it easy to find.

✅ tip: Use the Object ID (not the App ID).

👉 Alternative method: You can also find the service principal in the Azure Portal:

Go to Azure Active Directory > Enterprise Applications
Click + New application and select Managed Identities from the drop-down under Application type.
Find and select your resource from the list to view its service principal.

🧩 Step 3: Store the Managed Identity in a Variable

$msi = Get-MgServicePrincipal -ServicePrincipalId "<service_principal_id>"

Once you know which service principal you want to use save it to a variable, replace <service_principal_id> with the ID you want to use.

🧩 Step 4: Define the Permissions You Want to Assign

$myPermissions = @(
    "DeviceManagementConfiguration.Read.All"
    "Mail.Send"
)

Creates an array of permission values you want to assign from Microsoft Graph or another type of API. These will depend on the application for example you use SharePoint, Defender or graph as well as others. Each application has a consistent App ID that remains the same across all tenants.

🧩 Step 5: Get the Microsoft Graph API’s Service Principal

$graph = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

Gets the Microsoft Graph service principal object, which holds all available roles (permissions).

🧩 Step 6: Loop Over Your Desired Permissions and Assign Them

foreach ($myPerm in $myPermissions) {

    # find the permission in the graph service principal
    $permission = $graph.AppRoles | 
    Where-Object Value -Like $myPerm 
    | Select-Object -First 1

    # if permission found, apply it to the MSI
    if ($permission) {

        $appRoleAssignmentParams = @{
            ServicePrincipalId = $msi.Id
            AppRoleId          = $permission.Id
            PrincipalId        = $msi.Id
            ResourceId         = $graph.Id
        }

        New-MgServicePrincipalAppRoleAssignment @appRoleAssignmentParams -Confirm
    }
}

Loops through each desired permission.
Looks up the permission in Microsoft Graph’s app roles.
Builds the assignment with:
- PrincipalId: who gets the role (your MSI)
- AppRoleId: what permission to assign
- ResourceId: the app offering the permission (Graph)
Assigns the app role using New-MgServicePrincipalAppRoleAssignment

Even though the example here doesn’t have the ServicePrincipalId I found that I needed to include it if not I would just get prompted when I executed the command.

Conclusion

Managed identities are built into Azure resources and eliminate the need for passwords, making them a logical choice when using an Azure resource to perform tasks that require access to other cloud resources. They simplify authentication and enhance security by automatically managing credentials.

I haven't found a way to assign API permissions to managed identities in the Entra portal like you can with Service principals for app registrations which I have covered before in this post about Creating App Registrations for Intune API Access with PowerShell.

When you register an application in Entra, you'll need either a certificate or a secret to use the corresponding service principal in a PowerShell script or another client for authentication.

For well-known applications, a unique GUID is often provided. This GUID can be used to retrieve App Roles associated with those applications.

Computer things

Discussion about this post

Ready for more?