[CODE] Authentication with Azure PowerShell

As we all know Azure PowerShell is a very good tool to support your Azure Management activities. But when it comes to authentication to Azure we see quite a lot of confusion and frustration.

While in an interactive session, the authentication is pretty easy. When running scripts for automation without any interaction storing credentials becomes kind of an issue.

So let’s have a look which Authentication Options we can use when working with Azure PowerShell…

Interactive Sign-In

In your daily work you may use an interactive log-in when using Azure PowerShell. As you are actively working in the session it is not a problem to deal with prompts for authentication, MFA, etc.

The easiest way to start an interactive session is to use the Azure Cloud Shell. As the Cloud Shell automatically signs you in with your Azure AD credentials, you have an authenticated Azure PowerShell session right from the start.

When running Azure PowerShell in your own environment, you have to authenticate actively. The command is straight forward:

Connect-AzAccount

When running this command you will be presented with an interactive log-in dialog. This also handles all requests for MFA and additional authentication steps required, based on your security settings.

So it is pretty easy to connect to Azure via the Azure PowerShell. But if you want to run scripts automatically, based on a schedule …. manual authentication is not very practical.

Authentication with Service-Principal

When you are working towards automation with Azure PowerShell the usage of personalized accounts should be avoided for several reasons:

• personalized accounts should change there password on a regular basis, this could break you automation if not considered
• people can leave the company, which will result in a deactivation of the user account, which also will break you automation
• Credentials of the user account have to be stored anyhow, not so cool to have passwords of users saved anywhere
• Settings like MFA should be enabled for Admins in Microsoft Azure. MFA is not a good option in an automated job
• …

To avoid those problems you can use service principals. We have seen this in on-premises scenarios too, where we created Service-Accounts in Active Directory.

Azure Service Principals are non personalized accounts. They can get permissions like every other account via Azure AD. The good thing is, that you can assign specific right to this account, needed for the automation / task you aim for. So you are not automating with to many permissions.

To create a service principal you can use Azure PowerShell as well. With using the command

$sp = New-AzADServicePrincipal -DisplayName AZServicePrincipalPoSh

Choose whatever name you want as the DisplayName. It is important to create a variable with this command to store the output of the command. It includes the secret (the password of the service pricipal). It will not be printed into console. With the variable it is to convert the secret into a readable string.

Now you can use this service principal, to authenticate your PowerShell sessions. The username is the applicationID. Now just store the credentials outside your script, for example in a KeyVault or use the secrets feature in Azure Automation … and here you go

$pscredential = Get-Credential
Connect-AzAccount -ServicePrincipal -Credential $pscredential -Tenant $tenantId

Azure Service Principals also support a certificate based sign-in. More on this you can find in Microsoft Docs

Sign-In using Managed Identities

If your PowerShell runs on a resource in Azure you can use the Managed Identity Feature to sign-in. With the command

Connect-AzAccount -Identity 

you will get an one-time app-only access token. You can use this context then to access other resources in Azure.

As you can see you do not have to handle passwords, usernames or any other credentials. Nice feature, but be aware…only available for resources running in Azure.

Connect to Azure China, Germany or US Government

If you are running Azure Worklads in China, the old „German Cloud“ (RIP) or you are using the Azure US Government Cloud then you have to sign in especially into those environments using “ -Environment“:

Connect-AzAccount -Environment AzureChinaCloud

This will connect you to the required Cloud. This is necessary as those clouds use other instances of the Azure Resource Manager … so you tell the Azure PowerShell to run authentication against another API-endpoint

Happy PowerShelling

Dieser Post ist auch verfügbar auf: Englisch