Creating a Service Principal with Azure CLI


Service Principals are a bit of a weird beast. They are Azure Active Directory applicationswith kind of an extra bit. That bit says they can actually login by themselves. Hence the name principal. But being an application is kind of weird.

We covered Service Principals in the past. We covered how to create them using PowerShell.

Here I wanted to cover how to create them using the Azure Command Line Interface (CLI).

Short and sweet, let’s just do that.

Components of a Service Principal

A good way to understand the different parts of a Service Principal is to type:

az ad sp show --id <Object ID>

This will return a JSON payload of a given principal.

The following command will return the different credentials of the principal:

az ad sp credential list --id <Object ID>

With that we can sketch the important components for us:

Component Type Description
Display Name string Human readable name of the service principal
Owner Tenant ID Guid The tenant owning the service principal. This is useful if the principal was imported into our tenant.
App ID Guid The ID of the App.
Object ID Guid The ID of the App?
Credentials Array of credentials A principal can have multiple credentials. They each have a different validity time window.

First observation, let’s get it out of the way: the ids. Responsible for a lot of confusions, there are two. Each objects in Azure Active Directory (e.g. User, Group) have an Object ID.

An application also has an Application ID. Remember, a Service Principal is an application.

Some API will need the Object ID, others the Application ID.

To make matter worse they aren’t always refered to with those names. For instance, if we look at the documentation for az ad sp show -h, we get (at the time of this writing, i.e. mid-August 2018):

Show documentation

The tragedy here is that using the service principal display name doesn’t work nor does the object id. We need to use the Application ID. Hopefully, the documentation will be fixed by the time you read this.

So Object ID and Application ID are a little confusing and aren’t going anywhere soon. We just have to live with that fact. Now we are aware of it.

Another interesting aspect is that a principal can have multiple credentials.

This is useful to roll out credentials. For instance, we create a new credential a few days before the old one expires. We then have some times to roll out the new credentials while the old one is still active.

It is important to remember that credentials aren’t valid forever. They will simply stop working if not replaced.

We can also revoke credentials. This is very useful if a credential gets compromised.

Creating Service Principal

Now let’s get at it.

The basic command is az ad sp create-for-rbac. The issues with using it vanilla style, i.e. with no parameters are:

  • The display name is generated (e.g. azure-cli-2018-08-17-15-31-11)
  • There is one credential of type password valid for a single year
  • The service principal becomes contributor on the entire subscription

The first element is an inconvenience. We prefer to have meaningful display name as it facilitates operations.

The second can be ok in many cases. It is simply important to be aware of.

The third one is simply wrong. In this blog we keep professing the Principle of Least Priviledge and we’ll do it again. Giving too many access to an entity is opening attack surface.

So, instead we recommand using the following form:

az ad sp create-for-rbac -n <Service Principal Name> --skip-assignment

-n allows us to give our principal a display name. --skip-assignment skips the role assignment. That is, the principal isn’t given any access to our subscription.

We could have further customized by using a certificate instead of a password. We can also input a password instead of having one generated. We can also customize the date when the credential will be valid. Type az ad sp create-for-rbac -h for details.

Results

When our command executes, it returns a JSON payload such as this one:

{
  "appId": "fe9ef829-ecc5-4573-ba2b-a3c391de49ee",
  "displayName": "MyAksDelegate",
  "name": "http://MyAksDelegate",
  "password": "9dee4d72-8894-4028-977b-c05ca23dbd6d",
  "tenant": "72f988bf-86f1-41af-91ab-2d7cd011db47"
}

The appId property is the Application ID we talked about. It is important to remember.

The password is also important as it will be needed for the principal to authenticate.

Remains the elusive Service Principal Object ID. It will eventually be needed, so let’s find it now.

az ad sp show --id <Application ID>

Results

AppId                                 DisplayName    ObjectId                              ObjectType
------------------------------------  -------------  ------------------------------------  ----------------
fe9ef829-ecc5-4573-ba2b-a3c391de49ee  MyAksDelegate  e2b56ea3-98fa-4f01-8f0a-fbc080909bea  ServicePrincipal

We found our Object ID right there.

Summary

Hopefully those instructions here are useful to create a service principal.

We also explored a little bit what is going on under the hood.

Advertisements

6 thoughts on “Creating a Service Principal with Azure CLI

  1. Great post! az ad sp show –id –> this is the application ID, the Object ID for some reason doesn’t work.

  2. PERFECT Post, would you also point out the diff between Application and Service Principal? what is the relation between them? specially when it comes to Multi-Tenant environments? again thank you very very much!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s