Azure Automation account authentication overview
Azure Automation allows you to automate tasks against resources in Azure, on-premises, and with other cloud providers such as Amazon Web Services (AWS). You can use runbooks to automate your tasks, or a Hybrid Runbook Worker if you have business or operational processes to manage outside of Azure. Working in any one of these environments require permissions to securely access the resources with the minimal rights required.
This article covers authentication scenarios supported by Azure Automation and tells how to get started based on the environment or environments that you need to manage.
When you start Azure Automation for the first time, you must create at least one Automation account. Automation accounts allow you to isolate your Automation resources, runbooks, assets, and configurations from the resources of other accounts. You can use Automation accounts to separate resources into separate logical environments or delegated responsibilities. For example, you might use one account for development, another for production, and another for your on-premises environment. Or you might dedicate an Automation account to manage operating system updates across all of your machines with Update Management.
An Azure Automation account is different from your Microsoft account or accounts created in your Azure subscription. For an introduction to creating an Automation account, see Create an Automation account.
The Automation resources for each Automation account are associated with a single Azure region, but the account can manage all the resources in your Azure subscription. The main reason to create Automation accounts in different regions is if you have policies that require data and resources to be isolated to a specific region.
All tasks that you create against resources using Azure Resource Manager and the PowerShell cmdlets in Azure Automation must authenticate to Azure using Azure Active Directory (Azure AD) organizational identity credential-based authentication.
A managed identity from Azure Active Directory (Azure AD) allows your runbook to easily access other Azure AD-protected resources. The identity is managed by the Azure platform and doesn't require you to provision or rotate any secrets. For more information about managed identities in Azure AD, see Managed identities for Azure resources.
Managed identities are the recommended way to authenticate in your runbooks, and is the default authentication method for your Automation account.
When you create an Automation account, the option to create a Run As account is no longer available. However, we continue to support a RunAs account for existing and new Automation accounts. You can create a Run As account in your Automation account from the Azure portal or by using PowerShell.
Here are some of the benefits of using managed identities:
Using a managed identity instead of the Automation Run As account simplifies management. You don't have to renew the certificate used by a Run As account.
Managed identities can be used without any additional cost.
You don't have to specify the Run As connection object in your runbook code. You can access resources using your Automation account's managed identity from a runbook without creating certificates, connections, Run As accounts, etc.
An Automation account can authenticate using two types of managed identities:
A system-assigned identity is tied to your application and is deleted if your app is deleted. An app can only have one system-assigned identity.
A user-assigned identity is a standalone Azure resource that can be assigned to your app. An app can have multiple user-assigned identities.
User-assigned identities are supported for cloud jobs only. To learn more about the different managed identities, see Manage identity types.
For details on using managed identities, see Enable managed identity for Azure Automation.
Run As accounts
Run As accounts in Azure Automation provide authentication for managing Azure Resource Manager resources or resources deployed on the classic deployment model. There are two types of Run As accounts in Azure Automation:
To create or renew a Run As account, permissions are needed at three levels:
- Azure Active Directory (Azure AD), and
- Automation account
Azure Automation does not automatically create the Run As account, it has been replaced by using managed identities. However, we continue to support a RunAs account for existing and new Automation accounts. You can create a Run As account in your Automation account from the Azure portal or by using PowerShell.
You need the
Microsoft.Authorization/*/Write permission. This permission is obtained through membership of one of the following Azure built-in roles:
To configure or renew Classic Run As accounts, you must have the Co-administrator role at the subscription level. To learn more about classic subscription permissions, see Azure classic subscription administrators.
Azure AD permissions
To be able to create or renew the service principal, you need to be a member of one of the following Azure AD built-in roles:
Membership can be assigned to ALL users in the tenant at the directory level, which is the default behavior. You can grant membership to either role at the directory level. For more information, see Who has permission to add applications to my Azure AD instance?.
Automation account permissions
To be able to create or update the Automation account, you need to be a member of one of the following Automation account roles:
To learn more about the Azure Resource Manager and Classic deployment models, see Resource Manager and classic deployment.
Azure Cloud Solution Provider (CSP) subscriptions support only the Azure Resource Manager model. Non-Azure Resource Manager services are not available in the program. When you are using a CSP subscription, the Azure Classic Run As account is not created, but the Azure Run As account is created. To learn more about CSP subscriptions, see Available services in CSP subscriptions.
When you create an Automation account, the Run As account is created by default at the same time with a self-signed certificate. If you chose not to create it along with the Automation account, it can be created individually at a later time. An Azure Classic Run As Account is optional, and is created separately if you need to manage classic resources.
Azure Automation does not automatically create the Run As account. It has been replaced by using managed identities.
If you want to use a certificate issued by your enterprise or third-party certification authority (CA) instead of the default self-signed certificate, can use the PowerShell script to create a Run As account option for your Run As and Classic Run As accounts.
Run As account
When you create a Run As account, it performs the following tasks:
Creates an Azure AD application with a self-signed certificate, creates a service principal account for the application in Azure AD, and assigns the Contributor role for the account in your current subscription. You can change the certificate setting to Reader or any other role. For more information, see Role-based access control in Azure Automation.
Creates an Automation certificate asset named
AzureRunAsCertificatein the specified Automation account. The certificate asset holds the certificate private key that the Azure AD application uses.
Creates an Automation connection asset named
AzureRunAsConnectionin the specified Automation account. The connection asset holds the application ID, tenant ID, subscription ID, and certificate thumbprint.
Azure Classic Run As account
When you create an Azure Classic Run As account, it performs the following tasks:
You must be a co-administrator on the subscription to create or renew this type of Run As account.
Creates a management certificate in the subscription.
Creates an Automation certificate asset named
AzureClassicRunAsCertificatein the specified Automation account. The certificate asset holds the certificate private key used by the management certificate.
Creates an Automation connection asset named
AzureClassicRunAsConnectionin the specified Automation account. The connection asset holds the subscription name, subscription ID, and certificate asset name.
Service principal for Run As account
The service principal for a Run As account doesn't have permissions to read Azure AD by default. If you want to add permissions to read or manage Azure AD, you must grant the permissions on the service principal under API permissions. To learn more, see Add permissions to access your web API.
Run As account permissions
This section defines permissions for both regular Run As accounts and Classic Run As accounts.
- To create or update a Run As account, an Application administrator in Azure Active Directory and an Owner in the subscription can complete all the tasks.
- To configure or renew Classic Run As accounts, you must have the Co-administrator role at the subscription level. To learn more about classic subscription permissions, see Azure classic subscription administrators.
In a situation where you have separation of duties, the following table shows a listing of the tasks, the equivalent cmdlet, and permissions needed:
|Task||Cmdlet||Minimum Permissions||Where you set the permissions|
|Create Azure AD Application||New-AzADApplication||Application Developer role1||Azure ADHome > Azure AD > App Registrations|
|Add a credential to the application.||New-AzADAppCredential||Application Administrator or Global Administrator1||Azure ADHome > Azure AD > App Registrations|
|Create and get an Azure AD service principal||New-AzADServicePrincipalGet-AzADServicePrincipal||Application Administrator or Global Administrator1||Azure ADHome > Azure AD > App Registrations|
|Assign or get the Azure role for the specified principal||New-AzRoleAssignmentGet-AzRoleAssignment||User Access Administrator or Owner, or have the following permissions:
||SubscriptionHome > Subscriptions > <subscription name> - Access Control (IAM)|
|Create or remove an Automation certificate||New-AzAutomationCertificateRemove-AzAutomationCertificate||Contributor on resource group||Automation account resource group|
|Create or remove an Automation connection||New-AzAutomationConnectionRemove-AzAutomationConnection||Contributor on resource group||Automation account resource group|
1 Non-administrator users in your Azure AD tenant can register AD applications if the Azure AD tenant's Users can register applications option on the User settings page is set to Yes. If the application registration setting is No, the user performing this action must be as defined in this table.
If you aren't a member of the subscription's Active Directory instance before you're added to the Global Administrator role of the subscription, you're added as a guest. In this situation, you receive a
You do not have permissions to create… warning on the Add Automation account page.
To verify that the situation producing the error message has been remedied:
- From the Azure Active Directory pane in the Azure portal, select Users and groups.
- Select All users.
- Choose your name, then select Profile.
- Ensure that the value of the User type attribute under your user's profile isn't set to Guest.
Role-based access control
Role-based access control is available with Azure Resource Manager to grant permitted actions to an Azure AD user account and Run As account, and authenticate the service principal. Read Role-based access control in Azure Automation article for further information to help develop your model for managing Automation permissions.
If you have strict security controls for permission assignment in resource groups, you need to assign the Run As account membership to the Contributor role in the resource group.
We recommend you don't use the Log Analytics Contributor role to execute Automation jobs. Instead, create the Azure Automation Contributor custom role and use it for actions related to the Automation account.
Runbook authentication with Hybrid Runbook Worker
Runbooks running on a Hybrid Runbook Worker in your datacenter or against computing services in other cloud environments like AWS, can't use the same method that is typically used for runbooks authenticating to Azure resources. This is because those resources are running outside of Azure and therefore, requires their own security credentials defined in Automation to authenticate to resources that they access locally. For more information about runbook authentication with runbook workers, see Run runbooks on a Hybrid Runbook Worker.
For runbooks that use Hybrid Runbook Workers on Azure VMs, you can use runbook authentication with managed identities instead of Run As accounts to authenticate to your Azure resources.
- To create an Automation account from the Azure portal, see Create a standalone Azure Automation account.
- If you prefer to create your account using a template, see Create an Automation account using an Azure Resource Manager template.
- For authentication using Amazon Web Services, see Authenticate runbooks with Amazon Web Services.
- For a list of Azure services that support the managed identities for Azure resources feature, see Services that support managed identities for Azure resources.
Submit and view feedback for