App Dev Manager Herald Gjura demonstrates how to use PowerShell to automate the creation of Azure Service Principals.
Recently had to give a chalk talk on a Azure Service Bus (ASB). Creating and recreating the various topics and subscriptions is a bit of a pain since there are so many options and parameters to consider. The way I go about it is to create a utility that simply creates and destroys all the infrastructure I need for the chalk talk.
Many would say that the best way to create/recreate such items is through ARM json templates and they would all be right. however, my situation required something less industrious, so I maintained my habits of creating everything through code, via the new fluent ARM SDK (Microsoft.Azure.Management.ResourceManager.Fluent).
This came with a new challenge. For the Fluent ARM SDK to work, it requires for a Service Principal and AAD Application to be setup. Until now, I had always done this directly through the Azure Portal.
I was wondering if a more scriptable way existed? Perhaps through a PowerShell script?
Building the toolset
The post will be accompanied by the two PS scripts (Write-ServicePrincipal.ps1 and Read-ServicePrincipal.ps1). Only a few sections of those scripts are used here for illustration.
I love PowerShell when it comes to such tasks. It gets right to the point of what you want to do!
I set out to create two scripts: one that writes and creates the service principal and another one that reads from it.
Initially, I decided to break the process down and build a few PowerShell functions to help out with all the steps that were needed for this:
I needed a login function/script to log me into Azure. I have a Microsoft account (@live.com) and also have an enterprise account (@microsoft.com) as well as two Azure subscriptions (personal/MSDN and enterprise one from my employer).
I needed some flexibility in which account to use and which subscription to deploy, depending on the circumstances. PowerShell, has two distinct ways on doing the login from PowerShell depending on the type of account used.
I created this code snippet at the top of my PowerShell script:
It is rather simple: it prompts for credentials if it is a @live account and also provides an inline prompt for username/password for the corporate account. This provides flexibility to choose the account I want to work with.
Once logged in, I need to call in and get the subscription we want this service principal to go to. Without this, PowerShell will place it in the default subscription, which may not be the one intended.
get-resourcegroup, get-password, get-displayname, get-domainname
Next are a few functions that will facilitate the collection of info needed for the creation of the service principal. This is simple as well. When called with an empty parameter, these functions will prompt for you to enter the information, if called with a string parameter it will use that string as an input.
Next are two validation functions: one is to see if the service principal already exists and another to remove the AAD application if it does exist.
Next in line is the function that does all the work of creating the Service Principal and the associating AAD Application.
And finally, the scripts itself that puts everybody to work.
This section of the script collects the input values needed, creates the Service Principal and AAD App, and prints out the values I would need to enter in my software to work.
In the “INPUT VALUES” section, currently it will prompt you for all the values. You can uncomment the lines and provide your coded values if you don’t want to be prompted.
Once this is created, the values such as TenantId, SubscriptionId, ClientId, and Password, are usually all you need for an app to work with.
Have you ever wondered, “How do I get a tenant id, if I only know the domain name, of a domain managed by Azure AD?”. It is simpler than you think!
What I wanted to do here is provide a simple and scriptable solution on how to create a Service Principal and an AAD Application.
The two attached scripts (one for creating and for reading the service principal) you can copy and paste where ever you need such functionality, either in your CI/CD pipeline or your occasional code that you are writing.
For me, they were useful in deploying a Service Bus Namespace with all the topics and subscriptions, without going the way of a complex ARM json template (I am more of a code person.)
And how I made such deployment, and all the new features of Azure Service Bus, are the topic of the next blog post.