How to allow users to create service principals and the impact on Managed Identity

nillsf Azure, Management

A common question I get from customers is how they can enable their development teams to create service principals. In this post, I’ll explain how you can achieve this.

We’ll finish the post by exploring the impact on Managed Identities as well. During the writing of the Managed Identities piece, I hit something I hadn’t expected, so we’ll explore that topic in quiet some depth.

What exactly is a Service Principal

Before we dive into this, let’s focus on the semantics of the discussion, namely, what exactly is a service principal? The most easy definition of a service principal is that is an account an application will use to authenticate to Azure AD. It is similar to what a service account is in regular AD Domain Services.

One level of confusion in terminology, is that when you go into the Azure AD portal to configure a service principal, you’ll actually go into the ‘App registrations’ pane. So, another question is, what is the difference between an Application and a Service Principal? The answer is provided in detail in the Microsoft Documentation, but for a quick reply:

  • An application is the representation of an application across all potential tenants of that application.
  • A service principal is the representation of that application specifically in your Azure AD tenant.

In other words, an application will have 1 service principal for each Azure AD tenant it is used in. If you only have 1 tenant, both terms can be used interchangeably.

So, how can I allow users to create service principals without giving too many access rights?

Option 1: Allow everyone to create Service Principals

The first option – and the easiest option – is to give everyone in your organization the ability to create service principals. There is a toggle in the Azure AD configuration that enables you to allow everyone to create service principals.

Before we dive into the configuration, let’s think about what this means. Having the toggle activated, means everyone in your organization (everyone who has a login into Azure AD) can create Service Principals. This means, everyone can make an application, than can authenticate to your Azure AD instance. That’s just authentication, that has nothing to do with what those application can do. There’s a section of the Microsoft documentation that describes these permissions, and why it is not a bad idea to enable people to register application objects.

If you head on over to the Azure AD section of the azure portal, there’s a blade called user settings. This blade contains the option to enable users to create app registrations (aka service principals)

If you enable this option, all users will be able to create service principals. If you disable this, only certain administrators will be able to create service principals.

To demonstrate (and test) this, I’ll be using a fictional user called Ben in my own personal AAD tenant, who has no administrative role assigned to him – while this toggle is set to ‘Yes’.

With the toggle set to ‘Yes’, I can login as Ben, head-on over to App registrations blade and go ahead and create a new service principal:

If I now change this toggle to ‘No’ – I should no longer be able to create service principals.

Disclaimer: Changing the toggle actually works and limits the ability to create new Service Principals. In my case however, it did take a while for this new setting to become ‘active’. I didn’t exactly time how long it took, it didn’t work in the first 10 minutes, and then I took a dinner break and restarted the day after. Hence, no exact science from me here.

So, this now disables all users from registering service principals. As I mentioned before, the documents has arguments in favor of allowing everyone to be able to create application registrations. If however, you decide to limit this capability, there is a second option to enable people to create service principals.

Option 2: Administrator role in Azure AD

Azure AD has the concept of RBAC built-in. The RBAC of Azure AD is separate from the Azure RBAC that you apply to subscriptions and resource groups. Those are two separate control planes, with one exception: there is an option in Azure AD to would enable your Azure AD global administrator to have access to all Azure subscriptions (kind-of like a break-glass account).

Within the Azure AD RBAC, there is one role that specifically allows certain administrators to be able to create application registrations, or service principals. This role is called the “application developer” role. Let’s have a look at what this would mean for our fictional Ben.

To start, we’ll login as an actual administrator in Azure AD, and give Ben the role of Application Developer. For this, we head on over to Azure AD, select the Users blade and select our user Ben. Within his blade, we can select Directory role, and add an assignment for him to become an Application Developer.

Now that Ben is an application developer, let’s login as Ben in the Azure portal, and try registering an application (or service principal) again to see if this will work this time. And this works like a charm:

Disclaimer: I mentioned during option 1 that it took a while for the ‘no’ toggle to become active. In this case, giving a person a directory role had immediate success in my case.

What about Managed Identities?

While I am writing this, I am thinking to myself, what is the impact on Managed Identities? If you are unfamiliar with managed identities, let me quickly give you the highlights: Managed identities provide a mechanism for application running on Azure (either on VMs, Functions, App service or even pods in AKS) to get an identity in Azure AD. Those applications then can call an internal endpoint to get a oAuth token without having a certificate or a password. The benefit here is that you know where the application is running, and you trust that application. No need to store passwords or certificates (by you, as you’ll learn later on).

A managed identity will essentially create a Service Principal for you in Azure AD. Let’s see what impact the ability to create service principals has on the ability to create managed identities. My assumption is that:

  • Assumption 1: As long as Ben has to ability to create service principals, he’ll be able to create managed identities.
  • Assumption 2: If he doesn’t have the right to create service principals, he won’t be able to create those managed identities.

Let’s verify my assumptions. To do this, I’ll first give Ben access to my Azure subscription, using Azure RBAC. To do this, I’ll head over to the subscription blade, and add a role assignment making Ben a owner of my subscription.

Let’s log in as Ben – while he is still an application developer in Azure AD – and have him try to create a managed identity. For this, we’ll open the Managed Identities blade, and create a new one.

While Ben was an Application Developer in Azure AD, he could create Managed Identities. Proof is this I_am_dev identity:

Let’s now remove the Application Developer role from Ben, and see if he can still create managed identities. To check whether or not Ben can create service principals, let’s see if he can create application registrations:

So, Ben cannot create service principals. Let’s see if creating a new managed identity will also be blocked. This however, is not the case, meaning my second assumption was wrong. Why?

Deep dive: Why can I create Managed Identities when I cannot create regular service principals

Let’s look into this: Ben does not have the ability to create application registrations, but he does have the ability to create managed identities. How can this be?

Looking at the documentation for Managed Identities. This one states:

Through a create process, Azure creates an identity in the Azure AD tenant that’s trusted by the subscription in use.

Microsoft documentation

This would indicate to me that Azure itself will create the identity in my directory, and not actually the user that created the managed identity. Let’s have a look at the Azure AD audit logs to see what they have to say:

As you can see, there are 5 logs that are relevant here, the way I interpret what happened here (reading logs from bottom to top):

  1. The moment we created our first Managed Identity, the Managed Service Identity service principal gets registered in our AAD tenant.
  2. Second step, we see that that Managed Service Identity service principal creates our i_am_dev application.
  3. Third step, we see that we now remove the app dev role from Ben.
  4. Fourth step, we see that the MSI service creates a new SP, called i_am_not_dev.
  5. Fifth step, the Keyvault Certificate Rotation SP is registered to our AAD tenant, to allow the managed identity certificate rotation to happen.

My assumption now is that the Managed Identities Ben created, won’t show up as Ben’s applications, as he didn’t actually create them. Let’s check all of Ben’s ‘owned applications’:

Our managed identities (there are two now) don’t show up here. But it has to exist in our directory, shouldn’t it? Let’s use the CLI to figure out some more:

First step, let’s get a list of all our identities in our directory:

az ad sp list

This command gives a lot of output, let’s try to find out I_am_dev service principal:

az ad sp list -o table | grep -i i_am_dev

This command will output us a single line for our I_am_dev managed identity. To get the full details of this identity, let’s copy the id of the identity (the first GUID) do a full ‘show’ in CLI:

az ad sp show --id 35fd1a11-30d0-46ec-bd39-0321298b0023

This shows us a full json object reflecting our managed identity in Azure AD. What I found most interesting are these two parts of the JSON body:

"keyCredentials": [
    {
      "additionalProperties": null,
      "customKeyIdentifier": "35E9F5106D89CAC9B921A22473DED87FC992CB94",
      "endDate": "2019-12-28T15:20:00+00:00",
      "keyId": "f63e8eaf-5d43-40cd-8287-41b9f7d6722d",
      "startDate": "2019-09-29T15:20:00+00:00",
      "type": "AsymmetricX509Cert",
      "usage": "Verify",
      "value": null
    }
  ],

This first part contains a certificate that is being used by the service principal / managed identity. This certificate is used by Azure to authenticate the service principal. The Azure docs actually explain where/how this certificate is generated and stored:

Managed service identities and Azure VMs

In step 3 of the process diagram above, the info of the ARM generated service principal is stored in the instance metadata service (IMDS), along with a certificate. In step 5, when you call the IMDS, the IMDS will use this certificate to authenticate the service principal. What’s good to know here, as this is a managed identity, is that you don’t have to rotate these certs, Azure will do that on your behalf.

Second interesting part in that JSON body:

"objectType": "ServicePrincipal",
(...)
"servicePrincipalType": "ManagedIdentity",

Although this object is indeed a ServicePrincipal, Azure AD has a special type of service principals called ManagedIdentity, to identity that this is a managed identity.

Conclusion

Let’s wrap all of this up. The main question I wanted to answer was, “How can I enable developers to create service principals”. There are two ways to enable your dev teams to create those:

  1. Enable everyone in your org to register applications.
  2. Give your devs the application developer role in Azure AD.

We also explored the impact on Managed Identities, and were able to conclude that even if you cannot do application registrations, you’ll be able to create a Managed Identity.

Leave a Reply