Vincent-Philippe Lauzon's

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):

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.