Azure Active Directory (Azure AD) is a multi-tenant cloud-based identity and access management solution that is part of Microsoft’s Entra Identity platform product family.
You can read more about Entra and its integrated hybrid and multi-cloud identity and access solutions family at the following Microsoft site: https://www.microsoft.com/en-us/security/business/microsoft-entra.
In this chapter, you will learn how to secure and protect Azure AD identities.
We will break down this chapter into sections that cover how you can review your environments, including security posture, tenant-level identity and access management, password management and protection, security defaults, multi-factor authentication, and Conditional Access. We will then look at implementing Identity Protection and Identity Management services.
By the end of this chapter, you will have covered the following recipes to create secure Azure AD identities:
Before we look at any recipes, we will first introduce some concepts surrounding Microsoft Identity services. This will assist us in establishing a foundation of knowledge to build upon. We will start by looking at Active Directory (AD).
AD provides Identity and Access Management (IAM) and Information Protection services for traditional Windows Server environments. It was first included with Windows Server 2000 as an installable service.
AD provides different services in its portfolio and is used as a generic and umbrella term in many cases.
These individual services in Azure AD include the following:
In this next section, we will introduce Azure AD and look at its relationship with AD, a similar name but with different functions, capabilities, and use cases.
Before we go any further, we should clear one thing up: there is a common misconception that Azure AD must just be a cloud-based Software-as-a-Service (SaaS) version, but it is not!
It is easy enough why people (wrongly) think this may be the case; after all, Exchange Online and SharePoint Online are indeed exactly that, SaaS versions of their traditional infrastructure deployed platforms; if only it were that simple, though.
In many ways, Azure AD is like AD on the surface; they are both Identity Providers (IDPs) and provide IAM controls. Still, at the same time, they function differently and don’t yet provide a complete parity of capabilities, although quite close.
It is worth noting that Azure AD is constantly evolving to meet the requirements and demands of authentication and authorization of workloads and services to bring capabilities in line with those available in AD, such as Kerberos realms within Azure AD.
At the time of publishing this book, you cannot use Azure AD to 100% replace the provided capabilities of AD.
Depending on the scenario, it may be the case that your environments will never be 100% cloud-based for identity services. You may remain with Hybrid identity services – that is, both AD and Azure AD coexist in a connected and synchronized state.
Azure AD is a SaaS identity management solution that is fully managed and provides functions such as an IDP and IAM for managing and securing access to resources based on Role-Based Access Control (RBAC).
As Azure AD is provided as a fully managed service, there is no installable component such as Windows Servers and Domain Controllers (DC); zero infrastructure needs to be deployed by you.
The primary cloud authentication protocol used by Azure AD is based around using OpenID, OAuth, and Graph, whereas AD uses Kerberos and NTLM.
The hybrid identity approach allows you to synchronize objects, such as user objects and their passwords, between AD and Azure AD directories.
The main driver for hybrid identity within an organization is legacy AD-integrated applications that do not support cloud identity authentication protocols.
This capability provides users access to AD authenticated, and Azure AD authenticated using a single Common Identity and password.
The password synced to Azure AD is a hash of the stored hashed password; passwords are never stored in Azure AD, only the password hash. This capability is referred to as same sign-on, meaning you will be prompted each time to enter the same credentials when you wish to authenticate to resources.
This capability should not be confused with single sign-on (SSO), which does not prompt you again when accessing resources. The following diagram shows the relationship between AD and Azure AD:
Figure 1.1 – AD and Azure as a relationship
Azure AD Connect is a free downloadable tool that synchronizes objects between AD and Azure AD’s IDP directories; this establishes hybrid identities. Azure AD Connect provides additional functionality and capabilities and allows for Self-Service Password Reset (SSPR) through additional configuration.
You can continue learning more, should you wish, about hybrid identities and Azure AD Connect, by going to https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-azure-ad-connect.
For this chapter, the following are required for the recipes:
Figure 1.2 – Azure AD Premium P2 free trial activation
Azure AD Identity Secure Score enables you to make informed decision-making to protect your Azure AD tenancy.
This recipe will teach you how to monitor and improve your Azure AD Identity Secure Score.
We will take you through reviewing the Azure AD Identity Secure Score dashboard for your Azure AD tenancy environments and look at the actionable insights available to improve your secure score and security posture.
This recipe requires the following:
This recipe consists of the following tasks:
Perform the following steps:
Alternatively, in the search bar, type azure ad identity secure score; click on Azure AD Identity Secure Score from the list of services shown.
Figure 1.3 – Secure Score screen
This area of the screen shows three aspects to review:
Each recommended improvement action has a Score Impact, User Impact, Implementation Cost, Max Score possible, and Current Score:
Figure 1.4 – The Improvement actions screen
Figure 1.5 – Improvement actions download
Figure 1.6 – Improvement actions information
With that, you have reviewed Identity Secure Score. In the next task, we will update the status of improvement actions.
Figure 1.7 – Improvement actions status options
With that, you have updated the status of improvement actions. This concludes the hands-on tasks for this recipe.
In this recipe, we reviewed the information presented in the Azure AD identities Secure Score and took action from available insights.
You can also see actionable improvement insights on how your score can be improved and each improvement’s impact on the secure score.
The dashboard and a score history timeline show a comparison of your environment’s Azure AD tenancy to a tenancy of the same size and industry average.
Your environment’s Azure AD tenancy identity settings are compared with best practice recommendations once a day (approx 1:00 A.M. PST); changes made to an improvement action may not be reflected in the score for up to 48 hours.
Should you require further information, you can refer to the following Microsoft Learn articles:
Account compromise is one of the biggest threat vectors to protect against, and those with privileged access roles will be the focus of attacks. There are often too many users assigned privileged accounts, with more access than is required for a user to carry out their role. There is often insufficient RBAC in place, and the principle of least privilege should be adopted for these privileged administrator roles.
While we need to limit the number of user accounts that have the Global Administrator role, there should also not be a single point of compromise for the Global Administrator role. Having more than one account with the Global Administrator role is important. It is crucial to have an emergency account in case of a breach or conditional access lockout of a Global Administrator role assigned. Global Administrator role accounts can use a buddy system to monitor each other’s accounts for signs of a breach.
This recipe will teach you to ensure you only have the users assigned with the least privileges required for their role and ensure you have a minimum of two accounts assigned the Global Administrator role.
We will take you through the steps to implement these tasks.
This recipe requires the following:
This recipe consists of the following tasks:
Figure 1.8 – Azure AD Roles and Administrators screen
Select a user for users who no longer require the Global Administrator role and then click Remove assignments from the top toolbar:
Figure 1.9 – The Remove assignments screen
Figure 1.10 – Global Administrator Assignments screen
Figure 1.11 – The Assigned roles screen
Figure 1.12 – The Directory roles assignment screen
Figure 1.13 – User administrator | Assignments
With that, you have learned how to use least privileged roles. In the next task, we will designate more than one Global Administrator for the tenancy.
Figure 1.14 – Global administrator – the Add assignments screen
Figure 1.15 – Global administrator – The Add assignments screen
Figure 1.16 – Global administrator | Assignments
With that, you have created more than one Global Administrator role. This concludes the hands-on tasks for this recipe.
In this recipe, we looked at limiting the number of users with the Global Administrator role and ensuring you only had the users assigned with the least required privileges for their role. In our example, we removed the Global Administrator role from a user and reassigned them to the User Administrator role, which was the least privileges required for their tasks.
We then ensured you had a minimum of two accounts assigned the Global Administrator role by adding a user to this role. The Microsoft recommendation is for a minimum of two users and no more than five for this role.
Azure AD user accounts with the highest privileged role of Global Administrator will be the primary goal for compromise by bad actors. This is because this role has access to every administrative setting in your environment’s Azure AD tenancy at the read and modify permission level.
Microsoft recommends that you assign user accounts with less privileged roles. This limits the user’s scope of permissions through RBAC to only be able to do what a user needs to do for their job function.
The following are some of the many roles that can be considered to reduce the use of the Global Administrator role but still have enough access for a user to be able to perform their duties:
Should you require further information on least privileged roles, you can refer to the following Microsoft Learn articles:
Should you require further information, you can refer to the following Microsoft Learn articles:
Users often make poor choices when creating passwords, making them easy targets and victims of dictionary-based attacks.
This recipe will teach you how to implement Azure AD password protection in your environment’s AD tenancy. We will take you through customizing your smart lockout threshold and creating a global and custom banned password list.
This recipe requires the following:
This recipe consists of the following task:
Figure 1.17 – Azure AD Premium P2 free trial activation
Figure 1.18 – Azure AD Premium P2 free trial activation
With that, you have configured password protection. This concludes the hands-on tasks for this recipe.
You only need to add key terms such as password or contoso and the algorithm will automatically consider and block all variants of common character substitutions, such as Pa$sw0rd1! or C@ntos0!.
The banned password list may have a maximum of 1,000 key terms. The minimum length of a term string is 4 characters, where 16 characters is the maximum and are case-sensitive.
This recipe looked at customizing your smart lockout threshold to protect against brute-force attack methods. We also looked at creating a global and custom banned password list to protect against dictionary and password spray attacks and enforce the use of strong passwords.
Both of these measures, when implemented, can offer significant protection for your environment’s Azure AD tenancy.
Should you require further information, you can refer to the following Microsoft Learn articles:
Users will sometimes forget their passwords; to prevent intervention by an Azure AD administrator, a self-service password reset (SSPR) can be implemented. This allows users to click on the Can’t access your account? link on the sign-in page for the portal or Microsoft Cloud service they are trying to access.
This recipe will teach you how to implement SSPR in your environment’s AD tenancy. We will take you through enabling SSPR for a selected scope and review the available settings, then carry out a user registration for SSPR and test its operation to confirm the function is working.
This recipe requires the following:
This recipe consists of the following task:
Figure 1.19 – Password reset | Properties
Figure 1.20 – Password reset selected groups
Figure 1.21 – Authentication methods
With that, you have configured SSPR. This concludes the hands-on tasks for this recipe.
In this recipe, we looked at how we can implement SSPR when users forget their password for a portal or Microsoft Cloud service they are trying to access.
This prevents intervention from an Azure AD administrator, which reduces the burden on these roles and also protects against loss of productivity.
Should you require further information, you can refer to the following Microsoft Learn articles:
The perimeter vanishes with the rise in hybrid working and a remote workforce on unsecured devices outside of secure corporate networks. Now, it is commonplace to be targeted by identity-related attacks such as password spray and phishing. However, with basic security adoption, such as blocking legacy authentication and multi-factor authentication (MFA), 99.9% of these identity-related attacks can be stopped. However, we must balance security with productivity.
Because security can require skills and money, Microsoft is providing no-cost preconfigured secure settings by default to provide a basic level of security for everybody.
This recipe will teach you how to implement the Azure AD security defaults in your environment’s AD tenancy.
This recipe requires the following:
This recipe consists of the following task:
Figure 1.22 – The Enable security defaults screen
With that, you have enabled security defaults. This concludes the hands-on tasks for this recipe.
In this recipe, we looked at enabling security defaults in your environment’s Azure AD tenancy.
The security defaults are Microsoft-recommended security mechanisms with preconfigured security settings that, once enabled, are automatically enforced in your tenant to protect against the most common identity-based attacks.
The following are the enforced settings:
Should you require further information, you can refer to the following Microsoft Learn articles:
We must adopt a zero-trust strategy in the perimeter-less world of cloud services and hybrid working more than ever. This means that we must assume breach and never trust, always verify.
Azure AD MFA provides an additional layer of defense; we never trust a single authentication method and must assume that the traditional password method has been compromised. Microsoft studies show that when you implement MFA, your accounts are more than 99.9% less likely to be compromised.
This recipe will teach you how to implement Azure AD MFA in your environment’s AD tenancy.
This recipe requires the following:
This recipe consists of the following task:
Figure 1.23 – Multifactor authentication | Getting started
Figure 1.24 – MFA configuration screen
Figure 1.25 – MFA selected user pane
Figure 1.26 – Manage user settings pop-up screen
Figure 1.27 – Disabling MFA for a user
Figure 1.28 – The service settings tab’s settings
With that, you have configured MFA. This concludes the hands-on tasks for this recipe.
In this recipe, we looked at how to enable Azure AD MFA in our environment’s Azure AD tenancy to provide an additional layer of security for users to sign to protect their identity from compromise.
Azure AD MFA requires us to provide one or more additional factors as a method to authenticate in addition to the password factor.
We can use the following authentication factors:
Should you require further information, you can refer to the following Microsoft Learn articles:
There must be a balance of protecting an organization’s resources while ensuring every user, wherever they are, is empowered to be productive whenever.
To further strengthen our Azure AD identities, we can use insights from identity-driven signal data to make informed access control decisions and then use those decisions to enforce access policies.
MFA works alongside Conditional Access to provide further granular control of access.
Conditional Access is based on an IF/THEN approach. This approach means that IF signal information collected from the sign-in process matches certain criteria, THEN decisions are made based on the information as to whether access will be allowed or blocked.
Conditional Access will also determine whether the user will be required to perform additional authentication methods or take other actions, such as resetting their password. This is represented in the following diagram:
Figure 1.29 – Conditional Access concept
The following are some common Conditional Access policies:
This recipe will teach you how to implement Conditional Access policies in your environment’s AD tenancy. We will take you through enabling conditional access policies and configuring them to restrict user access to apps based on if a set of conditions have been met.
This recipe requires the following:
This recipe consists of the following task:
Figure 1.30 – Conditional Access | Policies
Figure 1.31 – User settings
Figure 1.32 – Apps setting
Figure 1.33 – App selection
Figure 1.34 – Conditions settings
Figure 1.35 – Access settings
Figure 1.36 – Access policies list
With that, you have configured Conditional Access. This concludes the hands-on tasks for this recipe.
In this recipe, we looked at how we can implement Conditional Access policies in addition to MFA to layer on an additional layer of defense while maintaining the users’ productivity needs.
We configured a Conditional Access policy to a set of selected users (or groups) that required MFA when they accessed the Azure portal; this was enabled by selecting the Microsoft Azure Management app.
Should you require further information, you can refer to the following Microsoft Learn articles:
We need solutions that provide remediation actions based on threat intelligence insights. Using policies, we can detect and respond to identity-based threats automatically; this allows us to react quicker and does not rely on human operator intervention.
This recipe will teach you how to implement Azure AD Identity Protection in your environment’s AD tenancy.
We will take you through setting up risk policies, MFA registration policies, investigation, reports, and how to remediate identified risks.
This recipe requires the following:
This recipe consists of the following task:
Perform the following steps:
Figure 1.37 – User risk policy
Figure 1.38 – User risk policy settings screen
Figure 1.39 – Sign-in risk policy settings screen
With that, you have configured Identity Protection. This concludes the hands-on tasks for this recipe.
This recipe looked at how to implement Azure AD Identity Protection.
A risk policy will monitor for identity risks, which, when detected, enforce remediation measures, which are the controls that have been set, such as blocking or allowing access and requiring a password change by the user.
Should you require further information, you can refer to the following Microsoft Learn articles:
To protect your environment’s Azure AD tenancy and improve your security posture, you should implement a robust privileged identity protection strategy for roles and resources.
This recipe will teach you to implement Azure AD Privileged Identity Management (PIM) in your environment’s AD tenancy.
We will take you through configuring a user to be assigned a privileged access role in your Azure AD tenancy so that the user’s activity may be controlled.
This recipe requires the following:
This recipe consists of the following task:
Figure 1.40 – The Privileged Identity Management screen
Figure 1.41 – The Azure resources blade
Figure 1.42 – Manage resources screen
Figure 1.43 – Select role
Figure 1.44 – Select member(s)*
Figure 1.45 – Assignments on the Overview page
Figure 1.46 – Assignments
Figure 1.47 – Assignment notification email
With that, you have configured Privileged Identity Management. This concludes the hands-on tasks for this recipe.
In this recipe, we looked at how to configure Privileged Identity Management. We assigned a user the Azure Arc Kubernetes Admin role.
Should you require further information, you can refer to the following Microsoft Learn articles: