Microsoft Entra ID

Microsoft Entra ID (previously referred to as Entra ID or AAD) is a cloud service that is responsible for managing cloud-based identities. In other words, it’s a directory of users, applications, and devices that are centralized and managed within defined boundaries (tenant). As mentioned earlier, it can be used with or without other Azure resources (such as subscriptions, resource groups, or cloud services).

Important note

Don’t confuse Microsoft Entra ID with Active Directory. Although they are quite similar in their functionalities and general purposes, Entra ID is not a direct replacement for its on-premises counterpart. It’s rather a service that addresses gaps in common on-premises environments by enabling an organization to provide hybrid identities for its principals.

To get started, we’ll discuss a little bit of terminology regarding the service.

Terminology

As Entra ID is quite a huge cloud component, it’ll be difficult in the beginning to understand all the concepts. We’ll focus on the most important ones and try to introduce advanced features a little bit later.

Here are the most popular concepts used when talking about Entra ID:

• Tenant – Simply put, a tenant is an Entra ID directory that contains users, applications, devices, and all the configuration related to the service.
• Identity – This is an object that can be anything that can be authenticated. Depending on the context, it could be a user, application, or external service.
• Entra ID roles – These are groups of permissions that allow a given object to perform a set of operations. Note that Entra ID roles are different than the roles that you’ll use in ARM.
• Entra ID licenses – There are multiple tiers of Entra ID that offer different sets of functionalities. Depending on the chosen tier, there’s either no charge or a charge per license.

There are also things such as service principals, app registrations, and enterprise applications, which we’ll describe later in the chapter.

Users and groups

In Entra ID, the most basic principal types are users and groups. A user is a person who got their account created in an Entra ID tenant. A group is a collection of users who were put in the same container.

User and their username

When a user is created, they get their username and password that are assigned by the Entra ID tenant administrator. A username is an equivalent of an email address, though it doesn’t mean that the user can automatically use it in their email client (in fact, it depends on the organization’s setup – a username in an Entra ID tenant may not reflect an email address used by a user).

To get things a little bit clearer, let’s imagine your company is named ITMasters and owns the itmasters.com domain. If there’s somebody in your company named John Doe, they most probably have an email address like [email protected].

This email address is used for both internal and external communication. Now, your boss has asked you to create an Entra ID tenant. Once the tenant is created, it automatically assigns the <yourcompany>.onmicrosoft.com domain to it. If you decide to create a user now, they’ll get the following username:

[email protected]

As you can see, the same person will have the following setup:

• Email address: [email protected]
• Entra ID username: [email protected]

Even though the Entra ID username looks like an email address, it’s not usable out of the box unless you introduce a change in the DNS zone, mapping this domain to your mail server. Fortunately, it’s possible to map a custom domain to an Entra ID tenant. We’ll describe that shortly.

Creating a user

The simplest way to create a user is to use either the Azure CLI or Azure PowerShell. Let’s see the syntax:

// Remember to run `az login` or `Connect-AzAccount` as the first step
// Azure CLI
az ad user create --display-name <display-name> \
  --password <password> \
  --user-principal-name <username>@<domain>
// Azure PowerShell
$PasswordProfile = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile
$PasswordProfile.Password = "<Password>"
New-AzureADUser -DisplayName "<display-name>" -PasswordProfile $PasswordProfile -UserPrincipalName "<username>@<domain>" -AccountEnabled $true

Let’s clarify those commands a little bit. As you can see, both the Azure CLI and Azure PowerShell require the same parameters (there are many other optional parameters available, but we’re not going to cover them here):

• Display name
• Password
• Username + domain

Display name and password are common parameters that are used to define the name of a user, which will be displayed (display name) with their password. There’s also a username and domain, which have the following requirement: the value of the domain parameter must reflect one of the validated domains.

For example, if you created an Entra ID tenant and assigned a custom domain (itmasters.com), you’ll have two validated domains available:

• itmasters.onmicrosoft.com
• itmasters.com

Now, when creating a user and defining their username, the following values would be accepted:

• [email protected]
• [email protected]

Assigning [email protected] couldn’t work unless you validate that you are the owner of that domain and then assign it to your Entra ID tenant.

Group types

In Entra ID, a group can be one of the following two types:

• Security – Used for simplifying the management of roles and permissions
• Microsoft 365 – Used for extending the capabilities of a group with a shared mailbox, calendar, and files

As Microsoft 365 groups are a concept that works mostly with Microsoft 365 tools, we won’t use them in this book. However, if your organization is working on integration with that platform, it will become helpful to you at some point.

Membership types

In Entra ID, you can select one of the available membership types. Each type defines a slightly different way of assigning members to a group:

• Assigned – You manually decide who is a member of a group and what their permissions are.
• Dynamic user – You can use the dynamic membership rule for the automated process of assigning and removing a user from a group. This feature is based on the user’s attributes and monitors them for possible changes.
• Dynamic device – This works in the same way as the dynamic user membership type, but in this case, it refers to devices.

Important note

The use of dynamic groups in Entra ID requires a paid license – Entra ID Premium P1 or Intune for Education.

Most Entra ID groups you’ll work with will be groups with the membership type set to Assigned. Still, the use of dynamic assignments and removals may be helpful in cases where you’re looking for optimizations in the process of group management.

Creating a group

Creating a group in Entra ID is even simpler than creating a user, as the only thing you need is to provide a name for a group and its members. There is, however, one gotcha – neither the CLI nor PowerShell, by default, enable you to provide advanced configuration of a group. That means that you cannot create an Entra ID group with a dynamic membership type out of the box, and you need to either install an appropriate extension or leverage the Azure portal or Entra ID admin center.

For the sake of our exercise, we’ll go for a simple example with a standard group using the assigned membership type:

// Remember to run `az login` or `Connect-AzAccount` as the first step
// Azure CLI
az ad group create --display-name <display-name> --mail-nickname <display-name>
// Azure PowerShell
New-AzureADGroup -DisplayName "<display-name>" -MailEnabled $false -SecurityEnabled $true -MailNickName "<display-name>"

As you can see, there’s a small difference between running the same command using the Azure CLI and Azure PowerShell. In the Azure CLI, you need to provide both a display name and a mail alias for that group (though, as we’re not using Microsoft 365 groups, it won’t matter). Azure PowerShell requires providing two additional parameters:

• MailEnabled – indicating whether mail is enabled for that group
• SecurityEnabled – indicating whether this group is a security group

Besides some differences in syntax, those two commands will create a group with the same configuration.

Applications and service principals

Users and groups are not the only concept when it comes to creating objects in Entra ID for managing access. Sometimes, you want to run a service or an application and give users or groups access to cloud resources. In those scenarios, Entra ID comes with a concept of applications and service principals, which work as an artificial user that can be assigned to an object outside the Entra ID directory.

Let’s consider the following situation. Somebody deployed an application to Azure; it’s a basic web application that connects to a database for obtaining data. Normally, that application can access the database using a connection string. An alternative would be to give it personality, so we can treat it as any other object inside Entra ID.

Another scenario would be an automation script that reads the metadata of Azure resources and builds a report indicating the current inventory of your cloud environment. As ARM integrates with Entra ID, that script must obtain a token that will be validated. To avoid passing our own username and password (which would be a serious security flaw), we could think about giving it an identity and receive a token based on that.

All these challenges can be solved by using applications and service principals in Entra ID. We’ll describe them in detail.

Service principals

Any entity trying to access a resource secured by Entra ID needs to have some kind of representation. If we’re talking about users or groups, things are simple – they are represented by appropriate objects in the directory. If that entity is an abstract concept, such as an application, script, or virtual machine, things require more advanced configuration.

In Entra ID, objects that are not users or groups will be represented by service principals. There are three different kinds available:

• Application – When you want to give access to Azure resources to an application or script, you can create an application object in Entra ID. Once that object is created, you may create a corresponding service principal object assigned to it. Service principal creation will also happen if the application is given consent to configured permissions (in scenarios where it can act on behalf of the user).
• Managed identity – This is a very specific kind of service principal as it’s closely connected to the development of applications and systems in Azure. The purpose of managed identity is to eliminate a need to programmatically obtain credentials for accessing Azure resources. It is assigned on a resource level and can be used from within the application’s code. We’ll talk more about it later in Chapter 11.
• Legacy – This is an old concept existing for backward compatibility. Before applications were added to Entra ID, service principals worked in a very similar way to the current app registration feature, which we’ll discuss in a moment. As this is a legacy feature, we’ll not use it throughout this book.

Let’s now talk a little bit more about a layer above service principals, which is the application layer.

Application

When talking about applications in Entra ID, we need to make a distinction between two related concepts:

• Application registration
• Application object

We already know that under the hood, each application consists of a service principal. However, a service principal is used to represent an application object on the authentication/authorization level. Before that happens, we need to delegate identity and access management to Entra ID. This is what application registration is for.

When we create application registration, we configure the way it’s going to be used. We can decide whether it’s a single or multi-tenant application. If we plan to use it to interact with user authentication flows, we’ll configure how authentication will be performed and how users will be redirected.

Once registration is completed, each application obtains a unique identifier (named ApplicationId or ClientId). This identifier will come in handy when connecting an application to other resources or creating role assignments.

Creating an application

To discuss applications in detail, let’s create one using the command line. Conceptually, this exercise isn’t much more difficult than creating a user or a group. However, we’ll split our demonstration between the Azure CLI and Azure PowerShell as they require slightly different approaches.

In the Azure CLI, you can simply use the following command:

// Remember to run `az login` or `Connect-AzAccount` as the first step
az ad app create --display-name <display-name>

This will create an application with the provided display name and default parameters. Note that we’re not passing additional configurations such as key type, optional claims, or delegated permissions (though it’s, of course, possible in more advanced scenarios).

In Azure PowerShell, you’ll need to install an additional Entra ID module:

Install-Module AzureAD

Then, we can create an application in the same way as in the Azure CLI:

// Remember to run `az login` or `Connect-AzAccount` as the first step
New-AzureADApplication -DisplayName "<display-name>"

The output of running these commands depends on the environment (the CLI versus PowerShell), but the result will be the same. Assuming I named my application AzureAdministrator01, I should be able to find its details using one of the available commands (az ad app show or Get-AzureADApplication). Unfortunately, it’s not as straightforward as we’d like it to be. Let’s see how to obtain that information.

Finding application details

As mentioned previously, we can use one of the two available commands for fetching information about an application:

• az ad app show
• Get-AzureADApplication

These two commands serve the same purpose but are used differently. The easiest way to get an application is to use its ApplicationId. ApplicationId is a unique identifier that is assigned to each application in Azure. If we know what value our application has, the whole thing will be a piece of cake. If we don’t, we need to approach it using available alternatives.

Get-AzureADApplication has a parameter called -Filter. Inside such a filter, we can provide the field and value we’re looking for. For example, for the aforementioned AzureAdministrator01, we could use the following command:

Get-AzureADApplication -Filter "DisplayName eq 'AzureAdministrator01'"

We’ll get a result with three columns – ObjectId, ApplicationId, and DisplayName. We’ll describe the difference between ObjectId and ApplicationId in a second.

In the Azure CLI, we could use a similar command, but the problem is that it accepts only one parameter. That parameter is –id and can be either ObjectId, ApplicationId, or the URI of the application. Not very helpful, is it? Fortunately, we could use a workaround with the following command:

az ad app list --display-name "AzureAdministrator01"

Alternatively, we could also leverage the –filter parameter like so:

az ad app list --filter "DisplayName eq 'AzureAdministrator01'"

All these commands can be used in the same context (though, obviously, the returned object will be slightly different for the CLI and PowerShell).

ObjectId versus ApplicationId

There’s always a little confusion when people realize that an application in Entra ID has two separate identifiers. When it comes to passing the correct identifier, there’s a moment of hesitation – should I use ObjectId or ApplicationId? Fortunately, the answer is quite simple.

We mentioned previously that when an application is registered in Entra ID, there’s a possibility to create a service principal so that the application can be authenticated and security policies can be applied to it. While the service principal itself is a separate being (at least conceptually), it’s attached to each application registration.

You can create a service principal for an application using the Azure CLI:

az ad sp create --id "<application-id>"

Once this command completes, it’ll create a new service principal object in Entra ID, which will be linked to your application. You can confirm that the service principal is created by running the following command:

az ad sp show --id "<application-id>"

The result will be a JSON object, which will contain an appId field containing the value of the ApplicationId field of your application. So, there’s even more confusion – now we have three separate identifiers (appId being the same for both objects, and two separate objectId identifiers):

• Application:
  • appId – 87be43fc-f329-4f1b-a6ad-9f70499e4e1d
  • objectId – f2b23bfe-53be-4ed4-8ba5-366b1f2fd06f
• Service principal:
  • appId – 87be43fc-f329-4f1b-a6ad-9f70499e4e1d
  • objectId – eed243a8-356e-4d5c-96bf-c603895a9645

Important note

The values of the fields presented previously will be different for each application and service principal you create. Don’t expect that they’ll be the same as in the examples from this book.

As you can see, the field that links both objects is appId. On the other hand, objectId is different for each of them. It’s important to remember how these fields are interpreted:

• appId is an identifier of an application
• objectId of an application is an identifier of that application within the Entra ID directory
• objectId from a service principal is an identifier of a service principal within the Entra ID directory

This distinction will become very important, for instance, when assigning a role to an Azure resource for an application. As a service principal is used for all the features related to security, you will need to use its objectId to create the proper assignment. appId, on the other hand, will be used when referring to an application itself.

Authenticating as a service principal

When using the Azure CLI or Azure PowerShell, you can use the following commands to authenticate:

Az login // CLI
Connect-AzAccount // PowerShell

They allow you to log in as a user and get access to resources within your Azure subscriptions.

Important note

The prior commands can be used even when there’s no subscription linked to an account. In such a scenario, you may need to use the --allow-no-subscriptions option in the Azure CLI to ignore the default mechanism of selecting a default subscription.

A scenario when you log in as a user is not always something you want – in fact, you will face many situations when you want to avoid providing your own credentials (e.g., when running an automation script). We talked a little bit about creating application registration and service principals. Let’s see how to use them to authenticate.

Each application in Entra ID can have credentials generated, which could be either a password or a certificate. You can list them using the Azure CLI, for instance, like so:

az ad app credential list --id "<application-id>"

As you can see, for this command, we are using the value of the appId field we saw earlier. For now, as this is probably an application we just created, there are credentials generated. We’ll change that with the following command:

az ad app credential reset --id "<application-id>"

As a result, you should receive output like mine:

{
  "appId": "87be43fc-f329-4f1b-a6ad-9f70499e4e1d",
  "password": "TaInm~…",
  "tenant": "c2d4fe14-…-5a65748fd6c9"
}

Note the value of the password field – we’ll use it in a moment.

Once we have generated credentials, let’s see whether we can authenticate as an application. Use one of the following commands:

// Azure CLI
az login --service-principal --username "87be43fc-f329-4f1b-a6ad-9f70499e4e1d" --password "TaInm~…" --tenant "c2d4fe14-…-5a65748fd6c9" --allow-no-subscriptions
// Azure PowerShell
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList "87be43fc-f329-4f1b-a6ad-9f70499e4e1d", "TaInm~…"
Connect-AzAccount -ServicePrincipal -TenantId "c2d4fe14-…-5a65748fd6c9" -Credential $Credential

Here’s a short clarification – to authenticate as an application, we must use three parameters:

• ApplicationId
• TenantId
• Password

In the Azure CLI, we’re also passing --allow-no-subscriptions as our application hasn’t been added to any Azure resources yet. Once authenticated, you will act as a non-user – the policies and roles normally applied to you as a user are no longer there because you’re not using your own account.

This scenario is very common in all the cases where you need to delegate running a script or an application to an object, which can be controlled by other members of your team or organization. Throughout the book, you will see that using an application (or service principal) will become one of the most common actions you do in Azure.

Let’s extend our knowledge of Entra ID with the next section of this chapter, where we discuss authorization using RBAC and ABAC.