Manage an Azure Automation Run As account
Azure Automation Run As Account will retire on September 30, 2023 and will be replaced with Managed Identities. Before that date, you'll need to start migrating your runbooks to use managed identities. For more information, see migrating from an existing Run As accounts to managed identity to start migrating the runbooks from Run As account to managed identities before 30 September 2023.
Run As accounts in Azure Automation provide authentication for managing resources on the Azure Resource Manager or Azure Classic deployment model using Automation runbooks and other Automation features.
In this article we cover how to manage a Run as or Classic Run As account, including:
- How to renew a self-signed certificate
- How to renew a certificate from an enterprise or third-party certificate authority (CA)
- Manage permissions for the Run As account
To learn more about Azure Automation account authentication, permissions required to manage the Run as account, and guidance related to process automation scenarios, see Automation Account authentication overview.
Renew a self-signed certificate
The self-signed certificate that you have created for the Run As account expires one year from the date of creation. At some point before your Run As account expires, you must renew the certificate. You can renew it any time before it expires.
When you renew the self-signed certificate, the current valid certificate is retained to ensure that any runbooks that are queued up or actively running, and that authenticate with the Run As account, aren't negatively affected. The certificate remains valid until its expiration date.
If you think that the Run As account has been compromised, you can delete and re-create the self-signed certificate.
If you have configured your Run As account to use a certificate issued by your enterprise or third-party CA and you use the option to renew a self-signed certificate option, the enterprise certificate is replaced by a self-signed certificate. To renew your certificate in this case, see Renew an enterprise or third-party certificate.
Use the following steps to renew the self-signed certificate.
Sign-in to the Azure portal.
Go to your Automation account and select Run As Accounts in the account settings section.
On the Run As Accounts properties page, select either Run As Account or Classic Run As Account depending on which account you need to renew the certificate for.
On the Properties page for the selected account, select Renew certificate.
While the certificate is being renewed, you can track the progress under Notifications from the menu.
Renew an enterprise or third-party certificate
Every certificate has a built-in expiration date. If the certificate you assigned to the Run As account was issued by a certification authority (CA), you need to perform a different set of steps to configure the Run As account with the new certificate before it expires. You can renew it any time before it expires.
Import the renewed certificate following the steps for Create a new certificate. Automation requires the certificate to have the following configuration:
- Specify the provider Microsoft Enhanced RSA and AES Cryptographic Provider
- Marked as exportable
- Configured to use the SHA256 algorithm
- Saved in the
After you import the certificate, note or copy the certificate Thumbprint value. This value is used to update the Run As connection properties with the new certificate.
Sign in to the Azure portal.
Search for and select Automation Accounts.
On the Automation Accounts page, select your Automation account from the list.
In the left pane, select Connections.
On the Connections page, select AzureRunAsConnection and update the Certificate Thumbprint with the new certificate thumbprint.
Select Save to commit your changes.
Grant Run As account permissions in other subscriptions
Azure Automation supports using a single Automation account from one subscription, and executing runbooks against Azure Resource Manager resources across multiple subscriptions. This configuration does not support the Azure Classic deployment model.
You assign the Run As account service principal the Contributor role in the other subscription, or more restrictive permissions. For more information, see Role-based access control in Azure Automation. To assign the Run As account to the role in the other subscription, the user account performing this task needs to be a member of the Owner role in that subscription.
This configuration only supports multiple subscriptions of an organization using a common Azure AD tenant.
Before granting the Run As account permissions, you need to first note the display name of the service principal to assign.
- Sign in to the Azure portal.
- From your Automation account, select Run As Accounts under Account Settings.
- Select Azure Run As Account.
- Copy or note the value for Display Name on the Azure Run As Account page.
For detailed steps for how to add role assignments, check out the following articles depending on the method you want to use.
- Assign Azure roles using the Azure portal
- Assign Azure roles using Azure PowerShell
- Assign Azure roles using the Azure CLI
- Assign Azure roles using the REST API
After assigning the Run As account to the role, in your runbook specify
Set-AzContext -SubscriptionId "xxxx-xxxx-xxxx-xxxx" to set the subscription context to use. For more information, see Set-AzContext.
Check role assignment for Azure Automation Run As account
To check the role assigned to the Automation Run As account Azure AD, follow these steps:
Sign in to the Azure portal.
Go to your Automation account and in Account Settings, select Run as accounts.
Select Azure Run as Account to view the Application ID.
Go to Azure portal and search for Azure Active Directory.
On the Active Directory Overview page, Overview tab, in the search box, enter the Application ID.
In the Enterprise applications section, you will see the display name of your Run As Account.
Select the application ID and in the properties page of that ID, go to Overview blade, Properties, and copy the name of the Enterprise application.
Go to Azure portal and search for your Subscription and select your subscription.
Go to Access Control (IAM), Role Assignment and paste the name of the Enterprise application in the search box to view the App along with the role and scope assigned to it. For example: in the screenshot below, the Run As Account Azure AD App has the Contributor access at the subscription level.
Limit Run As account permissions
To control the targeting of Automation against resources in Azure, you can run the Update-AutomationRunAsAccountRoleAssignments.ps1 script. This script changes your existing Run As account service principal to create and use a custom role definition. The role has permissions for all resources except Key Vault.
After you run the Update-AutomationRunAsAccountRoleAssignments.ps1 script, runbooks that access Key Vault through the use of Run As accounts no longer work. Before running the script, you should review runbooks in your account for calls to Azure Key Vault. To enable access to Key Vault from Azure Automation runbooks, you must add the Run As account to Key Vault's permissions.
If you need to further restrict what the Run As service principal can do, you can add other resource types to the
NotActions element of the custom role definition. The following example restricts access to
Microsoft.Compute/*. If you add this resource type to
NotActions for the role definition, the role will not be able to access any Compute resource. To learn more about role definitions, see Understand role definitions for Azure resources.
$roleDefinition = Get-AzRoleDefinition -Name 'Automation RunAs Contributor' $roleDefinition.NotActions.Add("Microsoft.Compute/*") $roleDefinition | Set-AzRoleDefinition
You can determine if the service principal used by your Run As account assigned the Contributor role or a custom one.
- Sign in to the Azure portal.
- Go to your Automation account and select Run As Accounts in the account settings section.
- Select Azure Run As Account.
- Select Role to locate the role definition that is being used.
You can also determine the role definition used by the Run As accounts for multiple subscriptions or Automation accounts. Do this by using the Check-AutomationRunAsAccountRoleAssignments.ps1 script in the PowerShell Gallery.
Add permissions to Key Vault
You can allow Azure Automation to verify if Key Vault and your Run As account service principal are using a custom role definition. You must:
- Grant permissions to Key Vault.
- Set the access policy.
You can use the Extend-AutomationRunAsAccountRoleAssignmentToKeyVault.ps1 script in the PowerShell Gallery to grant your Run As account permissions to Key Vault. See Assign a Key Vault access policy for more details on setting permissions on Key Vault.
Resolve misconfiguration issues for Run As accounts
Some configuration items necessary for a Run As or Classic Run As account might have been deleted or created improperly during initial setup. Possible instances of misconfiguration include:
- Certificate asset
- Connection asset
- Run As account removed from the Contributor role
- Service principal or application in Azure AD
For such misconfiguration instances, the Automation account detects the changes and displays a status of Incomplete on the Run As Accounts properties pane for the account.
When you select the Run As account, the account properties pane displays the following error message:
The Run As account is incomplete. Either one of these was deleted or not created - Azure Active Directory Application, Service Principal, Role, Automation Certificate asset, Automation Connect asset - or the Thumbprint is not identical between Certificate and Connection. Please delete and then re-create the Run As Account.