“A special type of Enterprise Application” you may ask. Aren’t we talking about Azure Managed Identities here? You are absolutely right! And yet, we cannot avoid talking about Enterprise Applications. I will explain below how this works.
If you are reading this article and are you wondering what Enterprise Applications actually are? Then I would like to point out my previous article, in which I explain what these are and the differences between Enterprise Applications (Service Principals) and App Registrations (Applications): The difference between AzureAD App Registrations and Enterprise Applications explained
What is a Managed Identity
To explain what a Managed Identity is, I take the following example: Suppose you have an application running on a virtual machine. And that data from this application is stored in an external SQL database. Then this application must have an account to retrieve and store its data from the database.
Until some time ago, it was necessary for this to have the data of this account stored somewhere on the virtual machine. This brought several limitations:
- Anyone with access to the virtual machine could read these credentials
- If the password or certificate expires, they must be updated on the VM
- Giving the account access to the data must be done on the SQL database
A Managed Identity is an Enterprise Application (so a Service Principal) within Azure AD, which is linked to an Azure resource (the virtual machine from the example). You can then log in within the Azure resource (VM) as this Enterprise Application without storing any credentials on the Azure resource (VM). With this account, you can then authenticate against other Azure resources (the SQL database from the example) that support Azure AD authentication.
An additional advantage is that you can use role assignments within Azure AD and Azure RBAC to assign rights to the Enterprise Application.
Flavors
There are 2 flavors of Managed Identities:
- System-assigned is directly linked to the Azure resource for which you are creating it. A system-assigned Managed Identity from one Azure Resource cannot be used by another resource. The moment you delete the Azure resource, the Managed Identity will also be cleaned up. So it shares the life cycle with the Azure resource that the Managed Identity is created with. An example is a workload that is contained within a single Azure resource.
You can create a system-assigned Managed Identity within the Azure portal by going to a supported Azure resource and choosing the “Identity” item from the menu.User-assigned is created as a standalone resource and is therefore not tied to the Azure resource’s lifecycle it is configured on. The big advantage is that the same user-assigned Managed Identity can be associated with more than one Azure resource. An example is a workload that runs on multiple resources and can share a single identity.
- For user-assigned Managed Identities, there is an independent place where you can create these within the portal: Search for “Managed Identities” within the portal or use this link
Create a Managed Identity
When you create a Managed Identity, almost the same thing happens in the background for both variants:
- First of all, a request is sent to Azure Resource manager to create a system-assigned or user-assigned Managed Identity
- After this, Azure Resource Manager creates a service principal (the Enterprise Application) in Azure AD
- In the case of a system-assigned Managed Identity, the Azure Resource manager will link it directly to the relevant Azure resource. This does not happen with a user-assigned Managed Identity (remember, as this is not linked to the Azure resource lifecycle). When linking, the Enterprise Application client ID and certificate of the Managed Identity are configured, which are required to use it later.
In the Azure AD audit log, you will then see that another service principal is creating a service principal (the Enterprise Application). If you look at the service principal’s details performing this action, you will see that it is the “Managed Service Identity”. This is a so-called Default AzureAD Enterprise Application, whose App Registration lives in a Microsoft tenant owns (with ID f8cdef31-a31e-4b4a-93e4-5f571e91255a). More information about default Azure AD Enterprise Applications can be found in my previous article: Default AzureAD Enterprise Applications explained, where do they come from?
The only thing you have left to do is giving the Managed Identity (i.e. the Enterprise Application) the correct rights to the resource you want to access (in the example used, this would be the Azure SQL database). You do this in the same place where you normally assign roles to users and groups.
Using Managed Identity
In the virtual machine example, there is an endpoint running within the virtual machine that is only accessible from within the virtual machine: The Azure Instance Metadata Service (IMDS). The moment you send a login request to this endpoint by using the configured Enterprise Application client ID and certificate, you will receive some data back, including an access token. This access token can then be used to authenticate against other resources that support authentication through Azure AD (such as Key Vault, Storage, SQL, Cosmos DB, etc.). This brings the following benefits:
- No credentials are stored on the virtual machine
- You will receive an access token, not the Enterprise Application credentials. When your access token expires, access also stops
- You do not have to maintain data on the virtual machine
