Using User Assigned Managed Identities with Microsoft 365 Automation

Using a User Assigned Managed Identity Requires Additional Setup but Can be Better in the Long Run

In my primer covering how to use Azure Automation to Run Microsoft 365 PowerShell SDK scripts (runbooks), I discuss using a system assigned managed identity for authentication. The beauty of system assigned managed identities (SAMI) is that they are simple to configure and use. The downside is that SAMIs are specific to an automation account and cannot be shared across multiple accounts. If you remove an automation account, Azure cleans up by removing the managed identities created for the account along with the service principal for the account. The process is clean, quick, and easy, and that’s why I tend to use SAMIs for Microsoft 365 automation.

If a tenant uses just a few automation accounts, the tied nature of SAMIs is not usually a problem. However, tenants don’t always limit their use of Azure Automation to PowerShell runbooks. Azure supports other automation capabilities such as Logic Apps, Function Apps, and virtual machines. It’s also true that a tenant might split processing across several automation accounts, each with their own Azure subscription. This might happen to allocate costs to different operating units that use Azure or to split management responsibilities. In these circumstances, a user assigned managed identity (UAMI) might be a better choice because it can be used with multiple resources and isn’t dependent on an automation account (see the Microsoft documentation covering this topic).

Creating a User Assigned Managed Identity

Creating a new UAMI is straightforward. Go to the Managed Identities section of the Azure portal and create the new identity by associating it with an Azure subscription and resource group. Give the identity a name and assign the region to host the resource. Once everything is ready, go ahead and create the identity (Figure 1).

Return to the Managed Identities section and select the identity you just created. The properties of the identity include a client identifier and object (service principal) identifier. The first identifier is used for authentication; the second when assigning Graph app roles (permissions) to the identity (Figure 2).

Assign Necessary Graph Permissions to a User Assigned Managed Identity

As mentioned above, the newly created UAMI has a service principal and therefore appears in the list of enterprise applications in the Entra admin center. Like SAMIs, a UAMI must be assigned Graph app roles (application permissions) to access data required by the runbooks it is used with. And just as with SAMIs, assignment isn’t supported by the Entra admin center and must be done using PowerShell.

First, store the service principal in a variable.

$TargetSP = Get-MgServicePrincipal -Filter "displayName eq 'UAMI2'"
$GraphApp = Get-MgServicePrincipal -Filter "appId eq '00000003-0000-0000-c000-000000000000'"

Now create an array of the permissions to assign:

$GraphPermissions = @(“AuditLog.Read.All”, “User.Read.All”, "GroupMember.Read.All”)

Finally, use the New-MgServicePrincipalAppRoleAssignment cmdlet to make the assignments:

ForEach ($GraphPermission in $GraphPermissions) {
   $AppRole = $GraphApp.AppRoles | Where-Object { $_.Value -eq $GraphPermission -and $_.AllowedMemberTypes -contains "Application"}
  
   If ($AppRole) { 
     Try {
       $Assignment = @{}
       $Assignment.Add("PrincipalId",$TargetSP.Id)
       $Assignment.Add("ResourceId",$GraphApp.Id)
       $Assignment.Add("AppRoleId",$AppRole.Id)

       $Status = New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $TargetSP.Id -BodyParameter $Assignment -ErrorAction Stop
       Write-Host ("Assigned the {0} permission to {1}" -f $AppRole.displayName, $TargetSP.displayName)
    } Catch {
        Write-Host "Failed to assign permission"
    }
  }
}

Although you can’t add or remove permissions for managed identities through the Entra admin center, you can check the assigned permissions there.

Remember that if the runbooks that the UAMI will be used with run cmdlets from other modules like the Exchange Online management module, you’ll need to assign an Entra administrative role to the service principal associated with the UAMI.

Link the User Assigned Managed Identity to the Automation Account

The final step before you can use the UAMI for authentication in a runbook is to link it to the automation account that owns the runbook. Remember, a UAMI is a shared identity that can be associated with multiple Azure resources. This step is often missed when dealing with UAMIs, especially if you’re used to the automatic association between SAMIs and Azure automation accounts.

Open the automation account in the Azure portal and go to the Identity section. You can work with both SAMIs and UAMIs here. Open the user assigned tab to view the UAMIs that are already linked. Because we’ve just created a new UAMI, we must add the UAMI as shown in Figure 3.

Authenticating with a User Assigned Managed Identity

If you’ve used SAMIs for authentication in a runbook, you know that the command to connect with the Microsoft Graph PowerShell SDK is:

Connect-MgGraph -Identity

The command to authenticate with a UAMI is:

Connect-MgGraph -Identity -ClientId <client id>

The client identifier tells Azure which UAMI to authenticate with. It is the client ID value of the UAMI (see Figure 2). You can hard code the value or store it in an automation variable. This runbook code shows how to use the Get-AutomationVariable cmdlet to fetch the value of the client identifier (stored as a string) and use it with the Connect-AzAccount and Connect-MgGraph cmdlets. You don’t need to connect to both endpoints – this code is just for demonstration purposes. Running Connect-MgGraph is sufficient if you only want to run Graph SDK cmdlets like Get-MgUser.

$UamiAppId = Get-AutomationVariable -Name "UAMIAppId"

Connect-AzAccount -Identity -AccountId $UamiAppId
Get-AzContext

Connect-MgGraph -Identity -ClientId $UamiAppId -NoWelcome

Write-Host "Connected to Microsoft Graph using user-assigned managed identity" $UamiAppId

Get-MgUser | Select-Object DisplayName

Although it’s true that connecting with a UAMI is more complicated than the simplicity of using a SAMI, it’s not hard and once you know what code to use, it’s a simple process. Most of the Microsoft 365 PowerShell modules support managed identities for authentication (SharePoint Online is a notable exception), but it’s always wise to test with a UAMI before committing to going down that road.

Deciding Between Managed Identities

Using system assigned managed identities is the easiest way for Azure Automation runbooks to authenticate with endpoints like the Microsoft Graph. It’s fast, secure, and works beautifully, which is why it’s my go-to method. But user assigned managed identities have their charms too, especially in large environments where it’s better to have identities that are resources in their own right rather than tied to automation accounts. The choice is yours!

---

Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Microsoft 365 for IT Pros eBook bundle.