Azure managed identities
Home » Identity » Managed Identities in Azure Automation (PowerShell)

Managed Identities in Azure Automation (PowerShell)

If you love Azure Automation and Security, you have probably heard that around April 2021, you could start using Managed Identities in Azure Automation to access resources securely.

This article will show why and how you should use Managed Identities to simplify your resource access management. And end it with showing how I have made my Graph API-related Runbooks much leaner.

The expected audience for this article is IT Pros with general experience managing access to Azure AD roles and Azure Resources.

What are managed identities?

Managed Identities are accounts in your Azure Active Directory that are only available for use by the resources that you have assigned them to. This could be an Azure automation account or some other service like Azure Functions or Azure VM. But it is not a given that they are supported in every type of Azure Resource.

The list of supported services/resource is found here: Azure Services that support managed identities – Azure AD | Microsoft Docs

Managed Identities come in two flavors

  • System assigned
  • User assigned

System assigned is tied to the lifecycle of a single resource (i.e., an Azure Automation account) much like a classic Active Directory managed service account (MSA), while User assigned can be thought of as a classic group managed service account (gMSA), that is available to multiple resources.

NB: At the time of writing, the only supported managed identity for Azure Automation is the System assigned identity.

How are they more secure?

Managed Identities are more secure because their “credentials” are only available to the resource they are assigned to, and they are never exposed in code. Unlike other account types that rely on an administrator to handle the credentials at some point, Managed Identities credentials are at no point handled by the systems administrator or anyone else. It is all handled by Azure, like a boss!

They are never exposed in code

Not having to deal with any form of credential (i.e., certificates or secrets) greatly enhances the security posture of the solutions you develop. And having to monitor for expired client secrets or certificates for app registrations is a thing of the past.

How do I get started with using Managed Identities in Azure Automation?

To get started with Managed Identities you first need an Azure Automation account. And I suggest you start with a fresh Azure Automation account in a new Resource Group that will hold you automation solution.

How to get started with Azure Automation itself is another topic entirely, but here are some good resources:

Create a standalone Azure Automation account | Microsoft Docs
An introduction to Azure Automation | Microsoft Docs

NB: When you create your new Azure Automation Account, a default option is to create a RunAs account. I would like you to consider not using that option during creation. It is not wise to enable RunAs accounts unless you will be using them. You will not be using RunAs accounts in this article because Managed Identities.

Actually using the managed identity for something cool!

First off, it is extremely easy to use a managed identity within your Runbook, once it is supported by the PowerShell modules that you use. Currently Az.Accounts is the only one that I have been using.

Using managed identities with the connect-azaccount cmdlet is very easy. simply install the Az.Accounts module into your Automation Account, and then in you runbook add:

Connect-AzAccount -Identity

Yes. It is that easy! You just connected to Azure using a managed identity.

But what about connecting to other Azure Services? Well, Microsoft has some great explanations on how to use Azure Key Vault to save credentials for many things and then only allowing the managed identity to access that key vault.

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

But like many IT Pro automation experts, I like to use Microsoft Graph a lot! But the Microsoft Graph PowerShell SDK does not yet support managed identities (*sad face*). Luckily Microsoft has also covered how to generate access tokens using the managed identity – but the article can be a little daunting for beginners, and understanding everything that goes on might not be for everyone…

Accessing Microsoft Graph API with a managed identity

There are many ways to work with Microsoft Graph API. I prefer the PowerShell SDK when working with the Microsoft Graph API in a Runbook since it will make it much leaner and less prone to errors than invoking web requests. Still, as mentioned earlier, support for managed identity is missing at the time of writing this.

The PowerShell module does, however, support the use of an access token. So we can simply call on the system assigned managed identity, to generate an access token that is valid for the Microsoft Graph API endpoint (Beta or v1.0). It is not as simple as the Connect-AzAccount cmdlet, but pretty close. Take a look at this code:

#Obtain AccessToken for Microsoft Graph via the managed identity
$resourceURL = "" 
$response = [System.Text.Encoding]::Default.GetString((Invoke-WebRequest -UseBasicParsing -Uri "$($env:IDENTITY_ENDPOINT)?resource=$resourceURL" -Method 'GET' -Headers @{'X-IDENTITY-HEADER' = "$env:IDENTITY_HEADER"; 'Metadata' = 'True'}).RawContentStream.ToArray()) | ConvertFrom-Json 
$accessToken = $response.access_token 

#Define the desired graph endpoint
$graphApiVersion = 'beta'
Select-MgProfile -Name $graphApiVersion

#Connect to the Microsoft Graph using the aquired AccessToken
Connect-Graph -AccessToken $accessToken

The comments probably gave it all away, but let’s just run through what is going on here…

Micro deep dive

First, we define the API URL that we know the Microsoft Graph API PowerShell SDK uses in the background, so if you want to use this for similar PowerShell modules, you need to figure out which Modern Authentication compatible URL they use on the backend and enter it here.

Please notice that I am not defining if it is beta or v1.0 when asking for a token, this is not needed.

Second, we build the Uri for our invoke-webrequest. Nothing special here, except the fact that we are using two very magic environment variables:


These two variables are only accessible by the automation account and only valid when processing the runbook. It’s sort of like a little private webserver within your runbook that you can send a request to. In this case, we are sending a web request that is, in fact, asking the managed identity service to go to the requested resource URL and get us an access token. We will then receive the access token as part of the response from the tiny private web service.

Lastly, we use the Microsoft.Graph PowerShell modules cmdlets to define the Profile we want to connect to, and then initiate the connection with our newly acquired access token.

The end result is a successful connection to the Microsoft Graph!

Assigning permissions to the Managed Identity

Assigning permissions to a managed identity is much like with any other service principal.

You can assign app permissions directly on the managed identity under enterprise applications where it lives and/or add the managed identity to a role in Azure AD and Azure that gives it the required access to the resources you need to access from Azure Automation.

Needless to say, you should assign the least required privilege.

Assign a managed identity access to a resource using the Azure portal – Azure AD | Microsoft Docs


Using managed identities to access Azure resources is easy and reliable. You should prioritize assessing if they can be used in your solutions from now and going forward. Since client secrets for app registrations are now limited to a maximum of 24 months expiration count, the risk of a service outage due to bad monitoring grows even bigger.

I hope this article helped you to understand that there is more to managed identities than meets the eye.

As always, I hope you will give your comments below and follow on twitter to show your support.


Michael Mardahl

Michael works as a Microsoft Certified Cloud Architect with APENTO in Denmark. He specializes in customer journeys from classic Infrastructure to Cloud consumption with a strong focus on security. And has been working in the IT industry for more than 20 years, where he started as a Network Administrator in the logistics industry. He has gained experience through a broad range of IT projects throughout the years and was very early to embrace and share his cloud technology passion. When not at work, Michael enjoys the value of spending time with family and friends and BLOG's passionately about Microsoft cloud technology whenever he has time to spare - this has earned him the title of Microsoft Most Valuable Professional (MVP) in the Enterprise Mobility category.

Add comment



Do you want to be notified of new posts on our site?

Please enter your email address below:

Categories use cookies to ensure that we give you the best experience on our website.