Using Managed Identities in Azure Automation Accounts (preview)

Whether it's to repeat common tasks or to automatically respond to a trigger, IT Pros look to to help streamline their work and improve their response times. In Azure, runbooks stored in Azure accounts need to use credentials of an identity that they will run their actions as, if they are acting on a Azure resource. Azure Resource Manager checks that identity against to ensure it has permission to the resource before the actions are executed. Lets look at the new managed identities for Azure (preview) and how they're better than the previous Run As accounts.

Run As accounts

Previously, we've used an Azure Automation “Run As” account for this execution identity. When you create an Azure Automation Run As account, it creates:

  1. An application with a self-signed
  2. A service principal account in Azure for that application
  3. And assigns the Contributor role to that service principal account in your subscription.
  4. It also creates an Automation asset to hold the 's private key, and an Automation connection asset which holds the application ID, tenant ID, subscription ID and certificate thumbprint.

That's a bit of complexity there, all to provide a secure identity. Also, that self-signed certificate will expire one year after creation and will need to be renewed.

System-assigned Managed Identity

Now in preview, Azure Automation supports using a system-assigned managed identity instead. This managed identity works with any Azure service that supports AD authentication and can be used in Hybrid jobs on Azure and non-Azure VMs with the Hybrid Runbook Worker. It removes the need for renewing certificates and you dont need to specify the Run As connection object in your runbook code.

Enabling managed identity in an Azure Automation account

In an existing automation account, in the Account Settings section you'll find the Identity blade and the option to turn on a system assigned identity.
Adding a system-assigned managed identity to your Azure Automation account - Identity blade inside the Azure PortalAdding a system-assigned managed identity to your Azure Automation account – Identity blade inside the Azure Portal

Once created, it will show the managed identity's Object ID and you can add role assignments at the subscription or resource group level, or to key vault, or SQL
Azure Automation account enabled with a system-assigned managed identityAzure Automation account enabled with a system-assigned managed identity

Now that your managed identity has been created and has a role that allows it to access your target resources, you can update your runbooks to use the Connect-AzAccount PowerShell cmdlet to call the managed identity:

Connect-AzAccount -Identity

View more sample runbooks here using managed identity.


As always, we love your feedback but especially for features in preview as we seek to improve them. What do you think? Is this a better way of providing your automation runbooks with an identity? Would you change over your existing Azure Automation accounts? Let us know in the comments!

Learn more:

Azure Automation account authentication overview

Manage an Azure Automation Run As account

Manage runbooks in Azure Automation

Enable a managed identity for your Azure Automation account (preview)

What are managed identities for Azure resources?


This article was originally published by Microsoft's PowerShell Community. You can find the original article here.