Using Azure Active Directory Service Principal

You need an Azure Active Directory (AAD) identity to run some of your services:  perhaps an Azure Runbook, Azure SQL Database, etc.  .

You could create a normal user in Azure Active Directory and use it.  If your AAD is synchronized with an on-premise one, it will get more complicated though.  You will need to create it on premise and wait for it to synchronize.  What if you organization activated double-factor authentication on the accounts?  Well, you can’t use the account for automation then because you won’t be able to just pass the credential in PowerShell.

Service Principal

The solution then is to use a Service Principal.  Concretely, that’s an AAD Application with delegation rights.  You can then use it to authenticate.

You can even give it RBAC permissions in Azure Resource Model, e.g. make it a contributor on your resource group.

Applications aren’t subjected to the same constrains as users.  For instance, they aren’t synchronized with On-Premise AD so you can go ahead and create them in any AAD.

Creating the Service Principal

Here I will refer you to the excellent article of Tom FitzMacken:  Create Active Directory application and service principal using portal.

The author walks you step by step on how to create & configure the AAD application.

Once you have it, you can use it by using the Application’s Client ID as the User Name and its key as the password.

Give rights to the Service Principal

You give rights to the service principal the same way you would for a normal user.

That is, from any resource or resource group in the portal, click the “Access” icon.


From there, click the Add  button.

Then first select a role (e.g. Contributor), then select the user.  You can use the Service Principal name here instead of its Client ID.

The role you selected determines the access.  You’ll typically want to give the least access possible (following the Principle of Least Privilege).

Using it in PowerShell

A key scenario is to use the Service Principal to authenticate in PowerShell in order to perform automation.  This could be from within an Azure Runbook, a PowerShell script or even a console.

You need to jump through some hoops in order to do that as the Azure PowerShell SDK requires secured string for the password.

First, create a secured string for your password:

$secPassword = ConvertTo-SecureString “My PASSWORD” -AsPlainText –Force

Then create the credentials:

$credential = New-Object System.Management.Automation.PSCredential(“My Client ID”, $secPassword)

And finally login to the Azure PowerShell SDK:

Add-AzureRmAccount -Credential $credential -ServicePrincipal -Tenant “My Tenant ID

Here it is important you specify the tenant ID as the Guid and not the name.

Following this you can use the Azure PowerShell SDK to do whatever the Service Principal can do.


I hope this looks simple enough.  There are a lot of catches along the way where the SDK will give you an error.

This showed you how to create a service principal to then use it to perform some action in Azure.

You could create multiple Service Principal for different types of action.  You could for instance create one to automate storage cleanup, another one to update VMs, etc.  .  You would then give different roles to each one.

Service Principal, i.e. AAD applications, have keys.  They can have more than one at the same time so you can roll them over in maintenance.

Leave a comment