Did you ever wanted to automate everything in Azure? Using Azure Automation or using Remote PowerShell – pretty much anything automated in Azure, you should NOT be using a stock standard user account. Why? Because you can have all sorts of problems, for instance the password can expire and then it breaks everything and everything stops working. It’s a bit like on-prem days where you would use specific service accounts, each service account setup for a specific purpose, much easier to manage and it’s best practice.
In Azure it’s no difference, you use a service principal and grant this service principal access to where ever in Azure with contributor or owner privileges.
The below script (run as admin) walks you through setting up an AAD application, creating the service principal, creating a self signed certificate then uploading the certificate to Azure.
There’s a section further below in the script to create all the Azure automation variables and sets up the certificate so you can use the Service Principal with Azure Automation. Remember, you need the certificate installed on the machine in which you want to connect automatically to Azure with using certificate based authentication.
Then further below is an example Azure Automation block of code clearly labled “Azure Automation PowerShell Workflow Runbook example” which you add to your own Azure Automation account as a starting point.
Below is how you would logon to Azure using PowerShell and certificate based authentication – as long as you have the certificate installed locally on the machine in which you are connection from, so you can successfully find the correct thumbprint.
See my other post to see how to setup an AAD Service Principal using password authentication instead.