0 
0 Introduction
I think that every production environment in Azure uses Automation Accounts for f.e. scheduled tasks. Up to recently, you were forced to use the Run As user to do so. This solution has, however, two drawbacks. The first one is that this Run As user has way too many permissions: by default it is contributor on subscription level [1]. The second, more important, drawback is that creating a Run As user is hard to implement in ARM templates [2].
Fortunately, Microsoft changed the way that permissions are granted to Automation Accounts: it is (finally!) possible to use Managed Identities with run books. According to the documentation, this is still in preview [3], but when you look in your Automation Account you will notice that there is no “(preview)” in the text of the menu item. The look and feel of managed identities in Automation Accounts in the Azure portal is the same as the look and feel of managed identities in other Azure resources.
Using a Managed Identity from the Powershell code in a run book is also pretty simple: you need just one command:
Connect-AzAccount -Identity
After this command the (new) Az Powershell commands can be used.
ARM templates
The way of working with Managed Identities in the Automation Account of ARM templates is pretty straightforward as well: it is done in the same way as for example Virtual Machines use managed identities [4].
The code part for a System Assigned Managed Identity in the Automation Account part of the ARM template is:
"identity": {
"type": "SytemAssigned"
}
When you use this, it works fine. The code part for a User Assigned Managed Identity called “automationIdentity” is:
"identity": {
"type": "UserAssigned",
"userAssignedIdentities": {
"[ResourceId('Microsoft.ManagedIdentity/userAssignedIdentities/', 'automationIdentity')]": {}
}
}
Unfortunately User Assigned Managed Identities are not implemented (yet). It is possible to deploy ARM templates with User Assigned Managed Identities without any errors. In the portal then everything looks fine, but when you start the run book you will get an error message:
Unable to acquire token for tenant 'organizations' with error 'ManagedIdentityCredential authentication failed: Service request failed.
Status: 400 (Bad Request)
Content:
{"Message":"No managed identity was found for Automation account a1234567-b890-1bc2-de34-56f78a901234."}
Headers:
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Date: Wed, 28 Apr 2021 12:55:38 GMT
Server: Microsoft-HTTPAPI/2.0
'
ManagedIdentityCredential authentication failed: Service request failed.
Status: 400 (Bad Request)
Content:
{"Message":"No managed identity was found for Automation account a1234567-b890-1bc2-de34-56f78a901234."}
Headers:
Transfer-Encoding: chunked
Content-Type: application/json; charset=utf-8
Date: Wed, 28 Apr 2021 12:55:38 GMT
Server: Microsoft-HTTPAPI/2.0
No subscription found in the context. Please ensure that the credentials you provided are authorized to access an Azure subscription, then run Connect-AzAccount to login.
Automation Account modules in ARM templates
I encountered some difficulties adding the modules to the Automation Account: when this is done from the portal, the portal “knows” where to find the modules. In ARM templates we have to provide the URL to the download website ourselves.
System modules for PowerShell modules are stored on the website www.powershellgallery.com. Searching on that site for Az.Accounts leads to the page https://www.powershellgallery.com/packages/Az.Accounts/2.2.8 . When you press on the tab “Manual Download” and then press on F12, then you can find the link that the button “Download the raw nupkg file” is referring to, this is https://www.powershellgallery.com/api/v2/package/Az.Accounts/2.2.8 . When you don’t provide the version number, it will download the latest version of this module.
System Assigned Managed Identities in action
I wrote an ARM template to demonstrate the System Assigned Managed Identity [5]. You can deploy the ARM template by using the commands
az group create --name AMISBlog --location WestEurope
az deployment group create --name AutomationAccountExampleDeployment --resource-group AMISBlog --template-file .\SystemAssignedManagedIdentitiesForAutomationAccounts.json
It will deploy an Automation Account and two virtual machines: vm1 and vm2. I added a System Assigned Managed Identity to the Automation Account and assigned “Virtual Machine Contributor” permissions to vm1. This is not done for vm2. To make it possible to use another Resource Group name than AMISBlog, the name of the resource group is stored in the variables part of the Automation Account. To make this work, extra quotes are needed for the value of the variable [6]:
"properties": {
"value": "[concat('\"',resourceGroup().name,'\"')]",
"description": "Resourcegroup where the VMs are in"
}
In the Automation Account there is a run book StopVM1, with the following code:
Connect-AzAccount -Identity
$ResourceGroupName = Get-AutomationVariable -Name ResourceGroupName
Stop-AzVM -Name vm1 -ResourceGroupName $ResourceGroupName -Force
When you start the StopVM1 run book, vm1 will be stopped. When you change vm1 into vm2 and then start the run book, then you will get the following error:
The client '39a12b34-56c7-8d9e-f0ab-1c2de3f4abcd' with object id '39a12b34-56c7-8d9e-f0ab-1c2de3f4abcd' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/deallocate/action' over scope '/subscriptions/abc12d34-e567-8901-f234-ab56cdef7a89/resourceGroups/AMISBlog/providers/Microsoft.Compute/virtualMachines/vm2' or the scope is invalid. If access was recently granted, please refresh your credentials.
ErrorCode: AuthorizationFailed
ErrorMessage: The client '39a12b34-56c7-8d9e-f0ab-1c2de3f4abcd' with object id '39a12b34-56c7-8d9e-f0ab-1c2de3f4abcd' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/deallocate/action' over scope '/subscriptions/abc12d34-e567-8901-f234-ab56cdef7a89/resourceGroups/AMISBlog/providers/Microsoft.Compute/virtualMachines/vm2' or the scope is invalid. If access was recently granted, please refresh your credentials.
ErrorTarget:
StatusCode: 403
ReasonPhrase: Forbidden
OperationID : 1ab2c3d4-5e67-89f0-123a-b2c34567890d
This is as expected: the System Assigned Managed Identity is connected to vm1, but it isn’t connected to vm2.
Links
[1] You can, however. change the default permissions of the RunAs command: see https://docs.microsoft.com/nl-nl/azure/automation/manage-runas-account
[2] See: https://dev.to/omiossec/runas-account-in-azure-automation-arm-template-and-deployment-script-56n8
[3] Microsoft site on Managed Identities with Automation Runbooks: https://docs.microsoft.com/nl-nl/azure/automation/enable-managed-identity-for-automation
[4] Managed identities with Virtual Machines: https://docs.microsoft.com/nl-nl/azure/active-directory/managed-identities-azure-resources/qs-configure-template-windows-vm
[5] See my GitHub account: https://github.com/FrederiqueRetsema/AMIS-Blog-Azure-2021, directory “Using Managed Identity with Azure Automation Accounts”
[6] See also: https://stackoverflow.com/questions/48170196/error-on-deployment-azure-automation-variable-assets
Image: https://www.stockvault.net/photo/264224/factory-robot-illustration
Related posts:
Azure Pipelines: Using and set up a webapp (part 1) Azure Pipeline: Build Angular and Node.js webapp (part 2) Add tests for Angular and Node.js webapp in Azure Pipelines (part 3) On-premise VM’s and Azure Pipelines: Set up with multiple stages in Azure Pipelines (part 4) Deploy Angular and Node.js webapp in Azure Pipelines (part 5)
