If you use Powershell to manage your Azure with Powershell you must have typed Login-AzureRmAccount and your credentials to login more times than you care to count. If you are like me and have MFA turned on in your AAD, it can a become tedious task. Although ARM, RBAC and the Azure AD integration is good for security, having to enter your credentials doesn’t work in automated batch environments, like pushing a build to Azure. If you are looking for a way to go back to the certificated way to authenticate, ServicePrincipal is for you (and you should continue to read).
ServicePrincipal – what is that?
There is probably an official way to describe it that but think of ServicePrincipal as a service account and not a user account. However, you need to start with an Application object in Azure AD, since you create the ServicePrincipal out of an Application object. The Application object is really just a placeholder here and acts like the I-am-your-father to the ServicePrincipal. You grant ARM RBAC rights, like Contributor, to the ServicePrincipal and then you go.
ServicePrincipal Authentication
The ServicePrincipal authenticates via a certificate, so we need to start by creating a self-signed certificate. So, first open an Azure PowerShell window as the administrator (elevated mode) and do the following:
First step is to do yet another Login-AzuerRmAccount using your userid and password. Then we generate a cert using New-SelfSignedCertificate and export it as a pfx file. This part will fail unless you are running the code in an elevated prompt with 0x80070005 ACCESS DENIED.
Creating the Application and ServicePrincipal in Azure AD
When creating the Application object you need to give it a name and attach the certificate to it. Azure AD will not allow you setting the EndDate some 40 years into the future, so you just have to live with the fact that it can only be valid for a year.
As you can see, the sequence New-AzureRmApplication, New-AzureRmServicePrincipal and New-AzureRmRoleAssignment is the three things that does the trick. Funny enough, the New-AzureRmServicePrincipal is the least complex call argument-wise. The -HomePage and -IdentifierUris are not important and are just set to nonsense values here. It’s the DisplayName and the KeyCredentials that are important.
Validating the ServicePrincipal login
You need to keep track of the TenantId, ApplicationId and Certificate Thumbprint and save the console output. Of those three, it’s the ApplicationId that you need to save somewhere from the creation steps above. The TenantId and the Cert thumbprint you can derive from info you have, but if you don’t save the ApplicationId you have to query it using Get-AzureRmADApplication -DisplayNameStartWith <your-name> from a ps window where you did the full Login-AzureRmAccount.
To test that it works you should close the ps window and open a new one. Then paste in the values of the Tennat, Application and Cert thumbprint and run the Add-AzureRmAccount. Voila!!
When you run it you will see in the output that the Account is a guid of the ApplicationId. In my case I granted the ServicePrincipal the Contributor rights so from here on I can do pretty much all I want with the subscription.
To move this to another machine I need to copy the pfx cert file and import it and the run the Add-AzureRmAccount on it – that’s it.
I used Azure Powershell version 1.0.4 from end of February 2016 when I got this to work.
Azure CLI
If you work mainly with Azure CLI instead of powershell you will be glad to know it works there too. You need to convert the pfx certificate file you have into the pem format. On Linux machines you have openssl already but if you run on a Windows laptop, the easiest way to get openssl is to download Win32 openssl from here http://slproweb.com/products/Win32OpenSSL.html and run the command
openssl pkcs12 -in .\AAD\cljungAzureServicePrincipal.pfx -out .\AAD\cljungAzureServicePrincipal.pem -nodes
to convert the certificate. Once you have the pem-file you can login as the ServicePrincipal in CLI
References
Authenticating a service principal with ARM.
This basically says the same as my article but in a more complex way
https://azure.microsoft.com/en-us/documentation/articles/resource-group-authenticate-service-principal/
Release notes of Azure Powershell 1.0
The code I showed can be found here. However, it’s missing that you need to run it in an elevated prompt and also that you need to Import-Module AzureRM.Resources
https://azure.microsoft.com/sv-se/blog/azps-1-0/
Sources
https://redbaron.blob.core.windows.net/public/Add-AzureServicePrincipalAccount.ps1