Entra ID, formerly known as Azure AD, is Microsoft’s cloud-based identity and access management service that integrates with the Azure platform and with other services such as Office 365, Dynamics 365, and Microsoft 365. Entra ID enables organizations to manage their users, groups, roles, applications, and resources in a centralized and secure way. However, like any system, Entra ID can be vulnerable to attacks from cybercriminals seeking to compromise an organization’s identity, access, or data. For this reason, it is important to perform regular penetration tests on Entra ID to assess its security posture and identify potential weaknesses or gaps.
In this article, we will explain some differences between Entra ID and the traditional Active Directory (on‑premises AD), as well as between Azure and Entra ID. By the end of this blog, we hope you will have a clearer understanding of what Entra ID is and how it is structured.
Before diving into the terminology and structure of Entra ID, let’s briefly review what Azure and Entra ID are, since they are sometimes confused or used interchangeably—especially because of Entra ID’s former name, Azure AD.
Azure is Microsoft’s cloud platform that offers more than 200 services to build, deploy, and manage applications and solutions in a global, scalable, and flexible environment. Some examples of Azure services include virtual machines, databases, storage, networking, artificial intelligence, analytics, security, and more.
Entra ID is one of Azure’s services, but it has a specific purpose: providing a cloud‑based identity and access management service for organizations that use Azure or other Microsoft services. Entra ID allows organizations to create and manage their own cloud domains (called tenants), where they can register their users, groups, roles, applications, and resources. In addition, Entra ID offers functionalities such as multi‑factor authentication, single sign‑on (SSO), device management, identity protection, access governance, and more.
Therefore, we can say that Azure is the general platform where Microsoft’s cloud services are hosted, while Entra ID is the specific service responsible for identity and access in the cloud.
Another common source of confusion is the difference between Entra ID and the traditional Active Directory (on‑premises AD), which is the directory service used in local environments to manage domains, users, groups, policies, and resources within a corporate network.
Although both services once shared the name Active Directory and some basic functionalities, there are several important differences between them:
▪️Architecture — On‑premises AD is based on a hierarchical architecture where domains are organized into trees and forests. Each domain has one or more Domain Controllers that store directory information and handle authentication and authorization requests. Entra ID, on the other hand, is based on a flat architecture where each organization has a single cloud domain (tenant). Each tenant has a distributed database that stores directory information and synchronizes with Entra ID’s global services.Once we have seen what Entra ID is and how it differs from on‑premises AD, we can now look at the structure of Entra ID and the elements that compose it.
The structure of Entra ID can be divided into four levels:
▪️Entra ID tenant — This is the highest level and represents an organization’s cloud domain. Each tenant has a unique identifier (tenant ID) and a name (tenant name). A tenant can have one or several associated subscriptions.In addition to these levels, there are two other important concepts to understand within the structure of Entra ID:
▪️App registration — This is the process through which an application is registered in Entra ID so it can use the cloud identity and access service. An app registration has a unique identifier (application ID) and a name (application name). An app registration can have one or more associated secrets that allow it to authenticate with Entra ID.
▪️Enterprise application — This is the process through which an application is configured in Entra ID so it can interact with other services or resources in the cloud or on the Internet. It is the instance or representation of the application within your tenant. An enterprise application has a unique identifier (enterprise application ID) and a name (enterprise application name). An enterprise application can have one or more permissions assigned to allow it to access other services or resources. Although it may request multiple permissions, you can define which permissions you actually want to grant. The access identity corresponding to an enterprise application is the Service Principal.
We can think of enterprise applications as the service account side of an application. The relationship between an app registration (the application itself) and a Service Principal (the enterprise application) is that the Service Principal represents the service account portion of an app registration. For example, if we have a multi‑tenant application, there would be only one app registration in the home tenant, but there would be an enterprise application in every tenant where the app is used. And we can assign Azure Roles to this enterprise application. For instance, an enterprise application could have Owner rights on a virtual machine or Contributor rights on a storage account.
▪️Managed Identities — Let’s suppose we have an application running on a virtual machine, and the data used by this application is stored in an external SQL database. In that case, the application needs an account to retrieve and store its data in the database. A Managed Identity is a type of Enterprise Application (therefore, a Service Principal) within Azure AD that is linked to an Azure resource (for example, the virtual machine). The resource (VM) can then sign in as this enterprise application without storing any credentials on the Azure resource itself. Using this account, the application can authenticate to other Azure resources (such as the SQL database) that support Azure AD authentication. An additional advantage is that you can use role assignments within Azure AD and Azure RBAC to grant permissions to the Enterprise Application.
The idea behind managed identities is to help developers handle secrets. If an application needs to store secrets such as user credentials, a managed identity allows the application to access a Key Vault that can securely store those secrets. This eliminates the need for developers to manage secrets directly, as the Key Vault handles that instead. However, this also means that if the application is compromised, the attacker could request an access token for the Key Vault and extract the stored secrets. .
In this post, we have reviewed what Entra ID is, as well as the differences between Azure and on‑premises AD. We have also looked at the architecture of Entra ID and some interesting concepts related to this type of platform. In the next article, we will explore techniques focused on pentesting in Entra ID.
See you next time.