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 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.


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>


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

We found our Object ID right there.


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

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

4 responses

  1. Anonymous 2018-09-07 at 02:12

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

  2. Anonymous 2018-09-07 at 02:21

    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!

  3. Vincent-Philippe Lauzon 2018-09-07 at 05:53

    A SP is an application. An application isn’t necessary a sp. A sp can authenticate while applications are authenticated against (see

    SP could be a completely separate concept to application. They have more in common with users than applications.

  4. Rogan 2018-11-29 at 05:58

    Hi Vincent, just a note/update, if you try and run the kubenet deploy you need to edit the templates kubernetes version to 1.11.4 (or whatever is supported currently) before it will be able to purchase and deploy. Hope that helps :)

Leave a comment