Default AzureAD Enterprise Applications explained, where do they come from?

Last week I posted an article (The difference between AzureAD App Registrations and Enterprise Applications explained) to which I received many responses. For many people, the difference between App Registrations and Enterprise Applications has become a lot clearer. I am therefore pleased that this was received so positively.

As a result of the above article I received quite a few questions, of which I will answer 1 in this new post:

I see various Enterprise Applications in my environment that I have not created myself. Where do they come from?

First of all, let me say that this does not necessarily mean something serious is going on. There are several reasons, and I will explain the most important one below.

Note: In my previous article, I always included both the Azure portal’s terminology and from within PowerShell. I have not done that here for simplicity reasons. The terms used in this article come from the Azure portal. Where App Registration and Enterprise Applications are mentioned, you can read Applications and Service Principals respectively.

Default Enterprise Applications

Do you remember the explanation from my previous article that an Enterprise Application is an App Registration instance? With the Enterprise Application in your tenant, the App Registration is able to offer a certain service that can communicate with the data that resides within your Azure AD directory. Perhaps the PowerShell terminology counterparts (Application and Service Principal) are a bit more descriptive of what functionality we are talking about here.

When a new tenant is created within Azure, there are several Enterprise Applications that must be present by default to make it possible for you to use them. These are also called Microsoft 1st party applications. A good example is the Azure portal. If you want to manage the new tenant, it might be handy that the application you’re using is allowed to do this. And the Enterprise Application for the Azure portal is necessary for this. Building on the example with the Azure portal, it basically works as follows:

You want to manage your Azure environment and decide to Sign in to the Azure Portal.
The Azure Portal is an Application (that lives outside your own tenant) that can use the App Registration from the tenant Microsoft owns.
In order for the Azure Portal to interact with your environment, an instance (the Enterprise Application) of the App Registration must be present in the tenant it wants to interact with.

This is just an example. There are some other Enterprise Applications that are standard available within your directory, which all refer to an App Registration. These are all App Registrations that live in an Azure AD Tenant that Microsoft manages. It isn’t easy to see via the Azure portal, but you can see it better via PowerShell.In this screenshot, you see an overview of the properties of the Enterprise Application object that belongs to the Azure Portal. Here you can see, among other things, the ID of the tenant, which is the owner of the App Registration (and where the Enterprise Application refers to). So, for all Enterprise Applications present in a new tenant by default, the App Registration lives in Microsoft’s tenant, with ID f8cdef31-a31e-4b4a-93e4-5f571e91255a.

The full list of standard Enterprise Applications is:

DisplayName	AppId
AAD Request Verification Service – PROD	c728155f-7b2a-4502-a08b-b8af9b269319
Azure ESTS Service	00000001-0000-0000-c000-000000000000
Azure Portal	c44b4083-3bb0-49c1-b47d-974e53cbdf3c
AzureSupportCenter	37182072-3c9c-4f6a-a4b3-b3f91cacffce
IAM Supportability	a57aca87-cbc0-4f3c-8b9e-dc095fdc8978
MCAPI Authorization Prod	d73f4b35-55c9-48c7-8b10-651f6f2acb2e
Microsoft App Access Panel	0000000c-0000-0000-c000-000000000000
Microsoft Graph	00000003-0000-0000-c000-000000000000
Microsoft Graph Change Tracking	0bf30f3b-4a52-48df-9a82-234910c4a086
Microsoft.SMIT	8fca0a66-c008-4564-a876-ab3ae0fd5cff
O365 Demeter	982bda36-4632-4165-a46a-9863b1bbcf7d
Office 365 Configure	aa9ecb1e-fd53-4aaa-a8fe-7a54de2c1334
Signup	b4bddae8-ab25-483e-8670-df09b9f1d0ea
Windows Azure Active Directory	00000002-0000-0000-c000-000000000000
Windows Azure Service Management API	797f4846-ba00-4fd7-ba43-dac1f8f63013

As some may already know, there are more Microsoft 1st party Applications. However, they are not immediately created when you request a new tenant. The moment you start using specific functionality that needs such an Enterprise Application, they will automatically be added to your directory. An example of this is Privileged Identity Management (PIM). As a result, there may be quite a few Enterprise Applications in your directory over time. You can find a more extensive list of these here: emilyvanputten/Microsoft-Owned-Enterprise-Applications (github.com).

Managed Identities

Lastly, you also have Enterprise Applications linked to a resource within your Azure environment, the so-called managed identities. The managed identities make it possible for an Azure resource (for example a Virtual Machine) to communicate with another Azure resource (for example a Storage Account) without storing login details on the virtual machine in this case. To make this possible, an Enterprise Application is required, so you have an identity to assign the required permissions to (via Azure AD and/or Azure RBAC). In a follow-up blog I will go deeper into how this works.