Manage an Azure Automation Run As account
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. This article provides guidance on how to manage a Run As or Classic Run As account.
To learn more about Azure Automation account authentication 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 certificate authority and you use the option to renew a self-signed certificate option, the enterprise certificate is replaced by a self-signed 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.
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.
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.