I’m currently working on a project where there has been a lot of discussion on how to use Azure AD Service Principals in Azure Automation and other solutions that involves any automated processes (i.e. VSTS pipelines).

When signing in to Azure using a Service Principal, you can use either a key (password) or a certificate associated to the Service Principal. When using the Add-AzureRMAccount cmdlet, you can use one of the following parameter set:

Key (password) based:

Azure AD Tenant ID

Azure Subscription Name or ID

PS Credential object

User name: Azure AD Application ID

Password: Service Principal key

Certificate based:

Azure AD Tenant ID

Azure Subscription Name or ID

Certificate (installed in the computer’s cert store)

Certificate Thumbprint

With Azure Automation, you have the option to create an Azure RunAs account via the Azure portal (Note: this option is only available from the Azure portal, not available in ARM APIs and templates)

When you create an Azure Run As Account using this wizard, the following objects get created:

Azure AD Application

Certificate based Service Principal for this Azure AD App that has contributor role to the Azure subscription where the automation account is located

An Azure Automation Certificate asset for the SP certificate

An Azure Automation connection asset that stores the following information:

Tenant ID

Subscription ID

Azure AD Application ID

Certificate Thumbprint

To be honest, I am not a big fan of using such RunAs account because of the following constraints:

1. There is no automated way to create it outside of Azure Portal.

These RunAs account looks pretty easy to create via the portal, but you cannot create them using an automated fashion (i.e. via ARM templates)

2. When creating it manually (via a PowerShell script), you’d normally create a self signed certificate, which requires local admin privilege.

When you create a self-signed cert using New-SelfSignedCertificate cmdlet, you must execute this command under a local admin (i.e. start a PowerShell window under local administrator). A workaround is to use an Azure Key Vault, generate a self-signed cert from the key vault then export it out. But obviously, you will need to provision a key vault prior to this step.

3. This RunAs account cannot be used in runbooks executed on Hybrid Workers

This is probably the biggest drawback. Since Azure Automation does not automatically deploy the certificate assets to Hybrid Workers, you will have to take care of this and manually deploy certificates to Hybrid Worker computers. However, since you cannot export any certificates from Azure Automation account’s certificate store, and the certificate created for the RunAs account is not exposed to you, there is no way you can deploy this certificate to the Hybrid Worker computers, therefore you cannot use this RunAs account on Hybrid workers (unless you manually create every components yourself outside of the Azure Portal and install the certificate to the Hybrid Worker computers).

4. The wizard only allows you to create one RunAs account for the subscription where the Automation account is located. You cannot create additional ones for other Azure subscriptions.

If you have runbooks that need to talk to other Azure subscriptions or AAD tenant, then you will have to manually create each required components and store them in your automation account.

5. A certificate installed on Hybrid Worker computer gives anyone who has access admin privilege to the computer ability to sign in to the Azure subscription

If you have access to the certificate, then you can easily obtain the cert thumbprint, as long as you know the Azure AD tenant ID and subscription Id (or name), you can sign in to the Azure subscription. This can be a potential security risk because server admins and Azure subscription admins can be 2 different groups of people. Also, if your Hybrid Worker computer is compromised, your Azure AD and subscriptions are also at risk.

Based on these reasons, I have been advising customers to use keys instead of certificates. To simplify the provisioning process and make everyone’s life easier, I have created a very simple PowerShell module called AzureServicePrincipalAccount. You can find this module in PowerShell Gallery and GitHub:

By the default, the Azure AD Service Principal connection type provided by Azure Automation accounts only supports certificate-based Azure AD Service Principals. This module provides an additional connection type for key-based Service Principals:

This module also provides a “proxy” function called Add-AzureRMServicePrincipalAccount to simplify the Sign-in process to Azure. This function allows you to pass either the built-in AzureServicePrincipal connection type or the Key Based AzureServicePrincipal type defined in this module, and it will determine the connection type automatically and sign in to Azure using the connection you have passed in. In another word, consider this as a universal sign-in function no matter if you are using the native certificate based SP connection, or a key based connection. Here’s a sample runbook:

Write-Error"Connection asset '$ConnectionName' does not exist in this Automation account."

}

Furthermore, you can also using this function without connection objects – by passing individual parameters for either the key or the certificate based Service Principals:

Although by using a key-based Service Principal, you still need to manually create the AAD application and service principals, there is nothing you need to configure on the Hybrid Workers. There are already many PowerShell sample scripts on how to create an Azure AD Service Principal, just for your reference, here’s one I’ve been using in the past:

If you are using a CI/CD tool such as VSTS, you can easily port this script to your pipeline and pass the Service Principal details to a ARM template that deploys the Module and connection object to an Automation account.