Getting started with Azure — Identities
In my previous blog post, “Getting started with Azure — Governance”, we explored some fundamental concepts on Microsoft’s cloud platform. Today we will continue that journey by taking a closer look at identities.
This content is once again taken from my Azure Practical Training, which is available for free. It is designed to guide beginners through Microsoft’s public cloud platform. The training includes the same content as this post but also provides exercises for hands-on learning opportunities.
What is Azure Active Directory
Azure starts with Azure Active Directory (which we often call AzureAD or use the acronym AAD). There is no other way. Even if you want to use a third-party identity management solution like Okta, you will still need to use Azure AD in between. So you have no option — you must get to know it well.
AzureAD is a Software-as-a-Service (SaaS) enterprise Identity and Access Management (IAM) solution. It is a cloud-based and multitenant service that offers:
- Aauthentication — it verifies users’ identities and issues access tokens,
- Authorisation — it verifies users’ access permissions to Enterprise Applications, which can be published via AAD.
Today, Azure AD offers a wide range of advanced security, collaboration, and other features besides the core identity and access capabilities. We will only explore some of them, as their scope is big enough to make it into a separate course.
The name of the service is, however, misleading. While we cannot use Azure without Azure AD, AAD is not a part of Azure, and many customers use it without ever thinking of deploying any Azure Resources. Azure Active Directory is also the backbone of other cloud-based services offered by Microsoft, like Microsoft 365 and Dynamics 365.
Therefore, I will often say, “Azure AD is not Azure”. While it sounds controversial, it’s a good rule of thumb for someone still finding their bearings in this domain. As we dive into various topics, you will understand better why I dare to say so.
Azure AD Glossary
Azure Active Directory introduces a fair bit of new terminology, and it is fundamental to understand what is what. We often use synonyms when referring to the same thing, so become familiar with the essential glossary below.
- Tenant — An essential word in our dictionary is the tenant. The tenant (often also called directory or domain) is a dedicated instance of Azure AD. Most commonly, it is intended for use by a specific organisation, but organisations can create additional tenants. As you probably remember from the previous chapter, all subscriptions belong to a single tenant — it is a tree-like structure. Therefore, creating several directories can make your governance very complex. One reasonable exception is separating end-user services like Microsoft 365 and infrastructure-focused Azure into different tenants. Due to the architecture of Azure AD (more on this very soon), such a setup can help with the separation of duties, especially when parts of IT are outsourced.
- Identity — An Identity is an entity that can be authenticated, for example, a user or an application.
- Account — An identity that has data associated with it.
- Azure AD account — An identity created through Azure AD or another Microsoft cloud service, such as Microsoft 365. Identities are stored in Azure AD and accessible to your organisation’s cloud service subscriptions. This account is also sometimes called a Work or school account.
Domains and Custom Domains
Every Azure AD tenant has a domain name used to identify the instance of the Azure Active Directory. The initial (mandatory) domain name follows the format:
<something of your choice>.onmicrosoft.com
The domain name must be globally unique because ADD is a multitenant SaaS offering.
The built-in domain name will always be there with you, but you can also add a custom domain name to make your Accounts’ User Principal Names (UPNs) more user-friendly.
The process of configuring a custom domain name is relatively simple and quick. It includes the following steps:
- Register a publicly-resolvable domain with a registrar of your choice
- Add the custom name in Azure AD (you will need Global Administrator permissions)
- Create the verification records in your domain’s lookup zone (Azure will ask you to create a specific TXT or MX record to verify ownership of the custom name)
- Wait for the DNS change to propagate and complete the process
Azure AD vs AD
Active Directory, also known as Active Directory Domain Services (AD DS) or Windows Server Active Directory (WS AD), is a service provided as part of the Windows Server operating system. It acts as a data store for users and devices on a local network and provides authentication and authentication mechanisms. While that description could also fit Azure Active Directory (and there is this naming similarity), it is a fundamentally different service. The key differences are shown in the following table:
Like with WS AD, users’ devices can authenticate to Azure AD. However, the situation is slightly more complex, as we have several models available:
- Azure AD-registered devices:
- Intended for the BYOD (Bring Your Own Device) scenarios
- Users sign in to their devices with local accounts
- An Azure AD account (work/school) grants access to resources
- Limited cloud security feature support
- Supports Windows 10+, iOS, Android and MacOS - Azure AD-joined devices
- Intended for cloud-first or cloud-only organisations (implemented only with organisation-owned devices)
- Users can only sign in to their devices with Azure AD accounts (work/school)
- Rich cloud security feature support
- Supports Windows 10+ and Windows Server 2019+ (in Azure) - Hybrid Azure-AD joined devices
- Intended for hybrid organisations with existing on-premises AD infrastructure
- Users can only sign in to their devices with organisational accounts
- Limited cloud security feature support
- Supports Group Policy for management
- Supports Windows 8.1+ and Windows Server 2008+
Azure AD Editions
In its default form, Azure AD is a free service. However, the free edition has limited benefits and features, so you will want to upgrade to Azure AD Premium in most production scenarios. To understand why, we will look at the following table, which provides an overview of the differences between various Azure AD editions:
The table, taken from Microsoft’s official documentation, could and should be more precise, especially on MFA. In a way, it hides the fact that Multi-Factor Authentication is not included in the free tier. At this point, you might feel the urge to point at the table and correct me. However, the Azure Active Directory free edition only provides MFA for accounts with administrative permissions in the tenant. And that group should be as small as possible.
To get MFA and another handy security feature called Conditional Access, you will need a P1 license. That should be your default for a regular user. However, considering the components required for people who manage Azure AD and Azure Resources, you should go for P2, as it gives you Privileged Access Management.
We will take a closer look at those security features very soon, but first, we need to get more familiar with a few other topics.
Azure AD Users and Groups
As you might expect from an IAM (Identity and Access Management) tool, user and group management is the bread and butter of Azure AD. While you won’t find any rocket science here, there are a few things to remember, so we’ll look at those now.
Users
In Azure AD, we have three types of users:
- Cloud Identities — created directly in Azure AD either via the portal graphical interface or programmatically as part of a scripted job
- Synchronised Identities — created in Azure by AD Connect — the WS AD synchronisation tool, which we will cover in the next chapter
- Guest Users — created in other Azure AD tenants and invited to your tenant (more on that later in this chapter)
Pro Tip! — when you delete a user in Azure AD, it is only soft-deleted and stays in the “bin” for 30 days. This feature allows you to recover an account deleted by mistake quickly. I’ve come to appreciate this option more than I’d like.
Groups
When it comes to Groups, in Azure AD, we have two options:
- Security manages user and computer access to shared resources. Owners can consist of users and service principals. Members can include users, devices, other groups, and service principals.
- Microsoft 365 provides collaboration opportunities by giving group members access to a shared mailbox, calendar, files, SharePoint sites, and more. It lets you provide people outside of your organisation access to the group. Members can only include users. Owners can consist of users and service principals.
But next to that, we have several assignment options:
- Static — in which you manually (or statically) assign group membership.
- Dynamic — in which the platform automatically assigns group membership for users or devices based on their attributes.
Important! — a dynamically assigned group can include only user objects or only devices, never both.
Administrative Units
I previously mentioned that Azure AD has a flat hierarchy and does not support Organisational Units like Windows Server Active Directory. There is, however, a feature that attempts to give us a fraction of what OUs did in WS AD — Administrative Units, also referred to as AUs.
AUs can be used to group Users, Groups, and Devices to delegate administrative tasks. That is both a lot and not enough at the same time — AUs cannot be nested (Azure AD is still flat) and support only certain permissions sets for administrators. Many permissions can only be scoped to the entire tenant.
They have, therefore, limited use when considering Azure Governance but can be of great value when delegating administrative permissions in end-user-focused scenarios.
Important! — You will need an Azure AD P1 license for every AU administrator. AU members can have a free license.
Application Service Identities
If you have experience working in a Windows Server environment, the concept of a service account should feel familiar. Working with applications that relied on Active Directory, we would create a regular domain user. Then, instead of giving it a human name, we would follow the naming convention for a service account and run a service in the context of that security principal. This way, we could permit that service to access file shares, databases, and other resources.
In Azure, we use different mechanisms. We will look at them in the following sections.
Service Principals
The first option is to use Service Principals (SPNs), which you can find in the Azure portal under App Registrations. An SPN is an Azure AD identity that an application (can be external) will use to authenticate to Azure resources. The authentication can use a secret (password) or a certificate.
In the simplest scenario, once you’ve imported the correct library into your source code, you need to pass the SPN ObjectId and the secret value to the application, and it can authenticate against Azure AD.
Managed Identities
Service Principals work well and are easy to use, but they come with a significant drawback — they leave you responsible for generating, securing, and managing credentials. In a growing environment, that task can become an impactful burden. But, thankfully, Managed Identities come to the rescue.
A Managed Identity is an Azure AD Service Principal managed by Azure. This short sentence above can take a few moments to sink in, but it is essential. As you hopefully remember, Azure AD is not Azure, but Managed Identities are one of the few places where the two services blend. An Azure AD security principal, represented and managed by Azure Resource.
A Managed Identity can be associated with an Azure Resource and used by that resource to access a target that supports Azure AD authentication and Azure RBAC. For example, we can assign it to a Function App and permit it to access a Storage Account. However, we never touch its credentials throughout this process and the remainder of the identity’s lifecycle. Those are generated and periodically rotated by Azure.
Managed Identities come in two flavours, and both have their use cases. The table below provides a comprehensive overview:
Multi-Domain Setup
Microsoft will (almost) always recommend having only a single Azure AD tenant. They have good reasons to provide such recommendations, and in many cases, it’s the best option. But there are situations in which you need to use several AAD domains.
Those special situations include the following:
- As part of a regulatory compliance framework, you need to separate the tenant of your production environment from any non-production environment.
- You work for a globally distributed enterprise, and data residency laws require storing data within a specific geographical region.
- You plan on outsourcing parts of your IT landscape to a 3rd party and want to retain a clear separation of duties. Remember — Azure AD has a flat structure, and some permissions can only be granted on the scope of the entire directory. AUs help with some things, but often we need more.
- You work for a managed service provider and must use a separate tenant for each customer.
I excluded from the list above a sandbox tenant you might use individually or in a shared setup with a limited group to learn and try new features and services. That is an extra one for the considerations above.
Important! — If you choose or are forced to use a multitenant setup, I strongly recommend keeping the number of directories to the minimum and paying particular attention to securing each one with adequate measures. Each of those tenants is a liability!
Azure AD Business-to-Business Collaboration
When you end up having multiple tenants, you could keep them completely isolated and create duplicate user accounts (and potentially groups) in every one of them, but that would be impractical. Also, you would eventually face configuration drift and potentially expose security vulnerabilities.
Thankfully, we have Azure AD Business to Business (Azure AD B2B) collaboration to mitigate this challenge. The service allows us to invite an Azure AD account from one tenant as a guest user in another tenant. If you remember Guest Users from earlier in this chapter, that was Azure AD B2B.
When you invite an external account into your tenant, your directory only stores a reference (pointer) to the Azure AD account in another tenant. When the user tries to authenticate, they are redirected to their home tenant, and once they obtain an authentication token, they are redirected back and authorised.
As a result, you can use a single Azure AD account to access multiple Azure AD tenants.
This service also works great when you want to give users from partner organisations access (like vendors and service providers) to a part of your Azure environment. Instead of creating (and managing) Azure AD accounts for them, you can invite them and let them use their existing identities.
In the example above, I talk about one Azure AD tenant inviting users from another ADD as guest users, but there are other options. You can also invite Microsoft, Google, Facebook (though with limitations) and other accounts. However, those scenarios are rare, and in many cases, they are not good practice. If you use someone’s work or school account, you can be reasonably confident that that account will be disabled or removed when they leave the organisation. On the other hand, inviting someone using their personal Microsoft account will place that responsibility on you.
Pro Tip! — The challenge I describe above can also be solved using Access Packages. We will not look at them here, but I encourage you to add the official documentation to your reading list, as several valuable use cases exist for that functionality.
Azure AD Busines to Customer
Azure also offers a Business to Customer service (Azure AD B2C), but the name can be misleading. You might expect similar behaviour after learning about B2B, but that is untrue. To use Azure AD B2C, you create a new, particular type of Azure AD tenant. That tenant is used solely to manage end-customer identities and their access to your applications.
Azure AD B2C offers a wide range of handy features that allow you to:
- integrate with external user stores,
- provide single sign-on access with a user-provided identity,
- create a custom-branded identity solution,
- use policies to configure user journeys,
- use progressive profiling to collect user information gradually,
- pass user data to a 3rd party for validation.
Azure AD RBAC
In the previous chapter, we explained how Role-Based Access Control works for Azure, but we never mentioned anything about Azure AD. But, since “Azure AD is not Azure”, it has its own RBAC stack.
How it works
Thankfully, Azure AD RBAC works almost the same as with Azure:
You create an assignment of a role definition to a security principal at a particular scope.
The main difference lies in the scope — while Azure can have an elaborate management hierarchy with several levels eligible for assignments, Azure AD is flat. We assign Azure AD RBAC roles to the entire tenant (and sometimes AUs).
Role Definitions
Because Azure AD is used for all cloud-based services offered by Microsoft, not just Azure, it has a long list of built-in role definitions. Most of those you will probably never need, but some are worth taking a closer look at:
1. Global Administrator can:
- Manage access to all administrative features in Azure Active Directory, as well as services that federate to Azure Active Directory
- Assign administrator roles to others
- Reset the password for any user and all other administrators.
2. User Administrator can:
- Create and manage all aspects of users and groups,
- Manage support tickets
- Monitor service health
- Change passwords for users, Helpdesk administrators, and other User Administrators
3. Billing Administrator can:
- Make purchases
- Manage subscriptions
- Manage support tickets
- Monitor service health
Apart from those three, I highly recommend that you check out GlobalReader, Groups Administrator, Application Administrator, and Security Administrator in the official docs from Microsoft.
Important! — Global Administrator is the highest permission level in Azure AD. The role allows you to do anything — the equivalent of root.
Where Azure AD RBAC meets Azure RBAC
The Global Administrator role is another one of the few places Azure AD and Azure come together. If you have this Azure AD role, you can navigate to the Properties section of the Azure AD blade in the Azure Portal and use the option “Access management for Azure resources”. Doing this will give you the User Access Administrator RBAC role in Azure RBAC (on the entire hierarchy). With that, you could create an assignment giving yourself the Owner permissions on any part of the Azure landscape.
Therefore, the Global Administrator role gives you unrestricted access to Azure AD and effectively to the entire Azure hierarchy within the tenant.
Azure AD Security
Finally, we will dive into some security features Azure AD offers. We won’t cover everything — we will focus on those I consider fundamental to maintaining a solid baseline security posture and those you might encounter during the exams. Also, remember that Azure AD is developed very dynamically — Microsoft is probably releasing new features as I write these words, so check the documentation for the latest and greatest.
Conditional Access
One of the fundamental security features of Azure Active Directory is Conditional Access. The feature analyses various signals to automate decisions and enforce organisational access policies.
The signals include, but are not limited to, the following:
- user identity and group membership,
- device platform,
- location,
- sign-in risk,
- client application.
Conditional Access policies are like if-then statements allowing or blocking access, enforcing multi-factor authentication, or restricting the user’s session.
You can create up to 195 policies in every AAD tenant but try to keep the number as low as possible and pay attention to how you name them. Reviewing a long list of configurations will make troubleshooting a painful experience, but even a short list will cause problems if your naming is inconsistent. Conditional Access configuration is not a place we look often, so in most cases, you’ll forget the details just a few weeks after you define your settings. Name them well, and your life will be easier!
Remember that Conditional Access will require Azure AD Premium — P1 for most features and P2 for Identity Protection. You will need the Security Administrator or Conditional Access Administrator RBAC role to configure the component. Global Administrator, as always, can do anything.
When you create a new policy, you can leave the default setting “Report-only” to evaluate its behaviour before you start limiting users’ sign-ins. But to ensure the security limitations you configure are in place, you must flip the switch to “On”.
Setting up conditional access is one of the first things I recommend configuring in your Azure AD tenant. Start with a simple set to provide a solid security baseline and build on top of that — limiting access to the Azure Management plane, enforcing MFA for all users and disabling legacy authentication protocols should be sufficient. Do exclude your break-glass accounts, though!
Multi-Factor Authentication
Multi-Factor Authentication (MFA) is another fundamental security feature of Azure AD. It requires users to verify their identity by providing two or more forms of authentication. Those forms include the following:
- something you know, like your account password
- something you are, like your fingerprint or face scan
- something you have, like a security key or your smartphone
The MFA service provided by Azure Active Directory supports the following forms of additional verification:
- Microsoft Authenticator
- Windows Hello for Business
- FIDO2 security key
- OATH hardware token
- OATH software token
- SMS
- Voice call
At the time of writing, we still have access to the legacy (I’m typically careful with the l-word, but a single glance at the UI takes us back in time more than a few years) interface for configuring MFA settings, but we also have access to the new one. The old interface is available via the “Multifactor authentication” section under “Security” in the Azure AD Blade, and the new one is under “Authentication methods”. The details of the migration are described here.
Multi-factor authentication is a relatively simple yet potent protection mechanism. A common saying reminds us that “identity is the new perimeter”, and enforcing MFA is the best thing we can do to help secure users in your organisation.
Identity Protection
Azure AD Identity Protection is a security service that detects potential vulnerabilities in your organisation’s identities. It uses existing anomaly-detection capabilities and introduces new risk-detection types based on Microsoft’s experience in Azure AD, Microsoft Accounts, and Xbox. Trillions of signals are analysed daily to identify and protect customers from threats.
Identity Protection’s signals can be used with Conditional Access or a security information and event management tool. It detects risks like:
- anonymous IP address use,
- atypical travel,
- malware-linked IP address,
- unfamiliar sign-in properties,
- leaked credentials,
- password spray,
- and others.
Access Reviews
Organisations can use Azure AD access reviews to manage group memberships, access to enterprise applications and privileged role assignments efficiently.
Self-service capabilities have made it convenient for users to join groups, invite guests, connect to cloud apps, and work remotely from their work or personal devices. However, this convenience has led to a need for better access management capabilities. As new users join, ensuring they have the access they need to be productive is essential. Similarly, removing their old access when they move teams or leave the company is critical. Excessive access rights can lead to compromises and result in audit findings, indicating a lack of control over access. To proactively manage access, resource owners should regularly review who has access to their resources.
Access reviews should be used in scenarios such as when there are too many users in privileged roles, and automation is not possible. For example, it is good to check how many users have administrative access and how many are Global Administrators.
For specific resources, it might be required as part of compliance processes to ask people to reconfirm and justify why they need continued access regularly. Finally, recurring access reviews can be set up for users at set frequencies such as weekly, monthly, quarterly or annually, and the reviewers will be notified at the start of each review.
Depending on the access you want to verify, you will want to use a different service/feature:
Security Defaults
Every new Azure AD tenant is preconfigured with security defaults to make things easier for customers. It’s a great starting point, but there are a few critical yet inconspicuous details. Let’s take a look at Microsoft’s description:
Security defaults make it easier to help protect your organisation from these identity-related attacks with preconfigured security settings:
- Requiring all users to register for Azure AD Multifactor
- Authentication.Requiring administrators to do multifactor authentication.
- Requiring users to do multifactor authentication when necessary.
- Blocking legacy authentication protocols.
- Protecting privileged activities like access to the Azure portal.
If you read it carefully, you’ll notice that all users must register for MFA, but only administrators will be challenged with a second factor upon every sign-in. Non-administrator users must only respond to an MFA challenge when necessary. However, the documentation is very vague about the circumstances that define the necessity.
Azure AD decides when a user will be prompted for multifactor authentication, based on factors such as location, device, role and task.
Therefore, getting a false sense of safety regarding the MFA configuration provided by the security defaults is relatively easy. Multi-Factor Authentication, in the most functional form, is only available with Azure AD Premium.
Improving Security
While I appreciate the security defaults as built-in protection, I need more. I would want my organisation to use more than the baseline level of protection, so I recommend you follow my hardening guide consisting of the steps listed below:
- Get Azure AD Premium for all your users. Many of you might find it controversial due to the associated costs, but damage control after a security breach is usually more expensive. It’s a good investment. Get a P1 license for all standard users and a P2 for Azure operators/administrators. The latter gives us Azure AD PIM, which we will cover in the next chapter, but it is another must-have feature.
- Disable the security defaults.
- Create three new Conditional Access policies to:
- Block access to the “Microsoft Azure Management” application from anywhere except your office/VPN IP ranges (exclude the break-glass accounts).
- Allow access for all users to all applications, but enforce Multi-Factor Authentication (exclude the break-glass accounts).
- Disable legacy authentication protocols. - Configure the following Azure Active Directory User Settings:
- Set ‘User can register applications’ to No
- Set ‘Restrict non-admin users from creating tenants’ to No
- Set ‘Restrict access to Azure AD Administration portal’ to yes
- Set ‘Allow users to connect their work or school account with LinkedIn’ to No - Configure the Azure Active Directory User Settings External collaboration Settings:
- Set ‘Guest user access restrictions’ to ‘Guest users have limited access to properties and memberships of directory objects’
- Set ‘Guest invite restrictions’ to ‘Only users assigned to specific admin roles can invite guest users
- Set ‘Enable guest self-service sign up via user flows’ to NO
- Set ‘Allow external users to remove themselves from your organisation to Yes
- Set ‘Collaboration restrictions’ to ‘Allow invitation only to the specified domains (most restrictive) ‘ and, if needed, and only the desired target domains.
Final words
Azure Active Directory, now part of Microsoft Entra, is a vast topic. In this blog post, I only focused on the Azure-related part, but there are also many great features that we haven’t touched.
If you have the time and the headspace, I recommend digging deeper. Otherwise, the topics I covered above should provide enough to make you productive and secure. And it should be sufficient for the AZ-104 and AZ-305 exams.
