- An application<\/strong> is the representation of an application across all potential tenants of that application.<\/li>
- A service principal<\/strong> is the representation of that application specifically in your Azure AD tenant.<\/li><\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
So, how can I allow users to create service principals without giving too many access rights?<\/p>\n\n\n\n
Option 1: Allow everyone to create Service Principals<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
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<\/em> do. There’s a section of the Microsoft documentation<\/a> that describes these permissions, and why it is not a bad idea to enable people to register application objects. <\/p>\n\n\n\n
If you head on over to the Azure AD section<\/a> of the azure portal, there’s a blade called user settings<\/a>. This blade contains the option to enable users to create app registrations (aka service principals)<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-47.png\")
<\/figure>\n\n\n\nIf 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. <\/p>\n\n\n\n
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’.<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-48.png\")
<\/figure>\n\n\n\n![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-49.png\")
<\/figure>\n\n\n\nWith 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:<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-50.png\")
<\/figure>\n\n\n\nIf I now change this toggle to ‘No’ – I should no longer be able to create service principals. <\/p>\n\n\n\n
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.<\/em><\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-51.png\")
<\/figure>\n\n\n\nSo, this now disables all users from registering service principals. As I mentioned before, the documents has arguments in favor of<\/a> 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.<\/p>\n\n\n\n
Option 2: Administrator role in Azure AD<\/h2>\n\n\n\n
Azure AD has the concept of RBAC built-in. The RBAC of Azure AD<\/a> 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).<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-52.png\")
<\/figure>\n\n\n\nWithin 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<\/a>” role. Let’s have a look at what this would mean for our fictional Ben. <\/p>\n\n\n\n
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.<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-53.png\")
<\/figure>\n\n\n\n![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-54.png\")
<\/figure>\n\n\n\nNow 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:<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-55.png\")
<\/figure>\n\n\n\nDisclaimer: 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. <\/em><\/p>\n\n\n\n
What about Managed Identities?<\/h2>\n\n\n\n
While I am writing this, I am thinking to myself, what is the impact on Managed Identities<\/a>? 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<\/em>).<\/p>\n\n\n\n
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:<\/p>\n\n\n\n
- Assumption 1<\/strong>: As long as Ben has to ability to create service principals, he’ll be able to create managed identities.<\/li>
- Assumption 2<\/strong>: If he doesn’t have the right to create service principals, he won’t be able to create those managed identities.<\/li><\/ul>\n\n\n\n
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.<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-56.png\")
<\/figure>\n\n\n\nLet’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<\/a>, and create a new one. <\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-57.png\")
<\/figure>\n\n\n\nWhile Ben was an Application Developer in Azure AD, he could create Managed Identities. Proof is this I_am_dev identity:<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-58.png\")
<\/figure>\n\n\n\nLet’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:<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-59.png\")
<\/figure>\n\n\n\nSo, 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.<\/strong> Why?<\/p>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-60.png\")
<\/figure>\n\n\n\nDeep dive: Why can I create Managed Identities when I cannot create regular service principals<\/h3>\n\n\n\n
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? <\/p>\n\n\n\n
- Assumption 2<\/strong>: If he doesn’t have the right to create service principals, he won’t be able to create those managed identities.<\/li><\/ul>\n\n\n\n
- A service principal<\/strong> is the representation of that application specifically in your Azure AD tenant.<\/li><\/ul>\n\n\n\n
![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-62-1024x137.png\")
<\/figure>\n\n\n\n![\"\"](\"\/wp-content\/uploads\/2019\/09\/image-61.png\")
<\/figure>\n\n\n\n![\"Managed](\"https:\/\/docs.microsoft.com\/en-us\/azure\/active-directory\/managed-identities-azure-resources\/media\/overview\/msi-vm-vmextension-imds-example.png\")
<\/figure>\n\n\n\n