I'm managing several Azure AD tenants with a wide variety of licenses and settings. I've had a focus on Azure AD Identity Protection for the last weeks, so I'm sharing my field notes with you.
What is Azure AD Identity Protection?
Let's start with a little introduction.
Microsoft has a lot of experience with identities in the cloud. These identities are used for public cloud features like onedrive.com and outlook.com, but also for the organizational cloud identities within Azure Active Directory.
With the presence of one or more Azure AD Premium 2 license(s) in the tenant, an organization can benefit from additional security options and automated actions to secure their organizational identities within that tenant. The global administrator account that is going to be used to activate the feature, should be enabled with a Azure AD Premium P2 license.
Azure AD Identity Protection Features
With the activation of Azure AD Identity protection, organizations benefit from the following features:
- Evaluates every sign-in sessions to existing sign-in behavior of the employee
- Evaluates the User Risk on the overall behavior and detection points
- Provides custom recommendations to improve overall security posture by highlighting vulnerabilities
- Integrates with Password protection within Azure AD
Microsoft obtains from several recourses passwords that are known on the Internet. With this information, Password Protection checks the existing password if the are known on the internet. If so, the user risk becomes high risk within Azure AD Identity protection. Depending on your policies, actions need to be taken before a employee can start working again.
- Provides investigation capabilities
- Provides an overview of all risk events and/or user accounts.
- Alerts the security team(s) of events
- Offers workflow capabilities so admins can
– Initiate immediate password reset
– Report false positive events
Risk-based (Conditional Access) policies
- Provides the capability to request additional user conformation, in sense of a multi-factor authentication or even block access, if a sign-in session is been found risky
- Provides the capability to request a password reset or even block access, if the user account has been marked to be at risk
- Integrates with Conditional Access as conditions
- Enforces MFA registration
Differences in Azure AD Identity Protection functionality between licenses
All the editions of Azure AD provide information on Risk Events and Risky Users. Depending on the edition, more features, information and controls become available.
- Azure Active Directory Free merely offers a list of users flagged for risk and a overview of risk events.
- Azure Active Directory Premium (P1) offers more access to the underlying risk events that have been detected for each report.
- Azure Active Directory Premium P2 offers the most detailed information about all underlying risk events and it also enables organizations to configure security policies that automatically respond to configured risk levels. To enable these policies and response mechanisms, admins need to configure Azure AD Identity Protection.
Note: Azure AD Premium 2 is part of the EMS E5 and Microsoft 365 E5 bundles, but can also be bought separately.
Screenshots of a Azure AD Free edition risk event and Risky user panel:
Screenshots of a Azure AD Identity Protection risk event and Risky User details panel:
Azure AD Identity Protection Configuration Options (P2-only)
This section shows the configuration options that are available for Azure AD Identity protection:
The first configuration item I want to explain is the ability to manage the MFA registration for the user accounts in use within the organization. This ensures that user accounts that are used to sign in to the Azure AD environment need to have the Azure MFA settings in place in order to continue:
The settings are stored in the strongauthenticationdetails attribute. These attributes can be reported upon.
The second configuration item controls what to do if Azure AD Identity Protection calculates that the user risk reaches the Medium or High thresholds. This risk is of the user object itself.
In the example below, the configuration is shown for the situation in which the user risk is High; the affected person need to change the password for his or her account, before he or she can continue working with it.
Note: When the identities are synchronized for an on-premises environment, it is my advice to enable the self service password reset (SSPR) feature for the Azure AD tenant.
The third configuration item governs the action based on the risk level of an actual sign-in session of a user account.
In the example below, the configuration shows that when a sign-in session is calculated to be Medium and above, an additional multi-factor authentication needs to be performed to validate the sign-in attempt:
Azure AD Identity Protection Alerts (P2-only)
When policies are in place, an administrator also should configure the notification e-mails to the intended department, when a risk level of a user account is calculated to be Medium or higher for example:
Here's an example of a notification e-mail and a weekly digest:
Let's look at the result of the configured policies from an end-user perspective, but also with the admin perspective following through.
In this example, my test user logs in via a Tor browser and provides his username and password. After clicking Next the sign-in is processed by Azure AD, Conditional Access and Azure AD Identity Protection. Due to a Tor browser being used, the session is marked suspicious and Azure AD asks me to perform an additional MFA challenge, to verify the sign-in attempt:
After a successful MFA challenge, my test user can continue to use the Office 365 portal:
Azure AD Identity protection will report this session to the configured recipients in the alert page. And also the event is visible in the report, but marked Closed (resolved) due to the MFA challenge resolution in the policy:
User Risk sign-in
When a user account hits a risk level of High, the policy states that he or she should change the password for the account before he or she can continue. I recreated the High user risk level by using the Tor browser again to sign-in several times, starting the MFA challenge, but not completing it on all occasions.
In Azure AD Identity Protection the user account is now listed with a High risk level and the password needs to be changed. The configured alert recipients receive another e-mail with the notification that a user is at risk.
And if the person now tries to login in to the web portal under normal circumstances the following happens:
- The person who signs in needs to perform an MFA challenge:
- The person needs to update the password for his or her account:
- After a successful change, the person now has access to his or her Office 365 portal:
Microsoft provides organizations the ability to see if cloud identities are at risk independent of licenses. As an admin, use this to your advantage and take this into account for the health/assessment processes of your environment; include this in your security reports. Additionally, if your tenant is equipped with Azure AD Premium P1 or Premium P2 licenses, ensure you use password protection.
When your Azure AD tenant is using Azure AD Premium P2 licenses, expand your identity defenses with Azure AD Identity Protection. Make use of Microsoft's knowledge and resources to minimize security breaches.
2 thoughts on “Field notes: Azure AD Identity Protection”
Hi, nice blogpost! You write: " With the presence of one or more Azure AD Premium 2 license(s) in the tenant, an organization can benefit from additional security options and automated actions to secure their organizational identities within that tenant. The global administrator account that is going to be used to activate the feature, should be enabled with a Azure AD Premium P2 license. " Can I, for example, use the MFA registration for all my users by buying only 1 AD P2 license? Is that allowed?
It works, but is not allowed.
There is a difference between what is technically needed to make a feature work and the product use rights that are part of licensing. When a person 'directly or indirectly benefits', then a license is required. In the case of MFA registration, everyone directly benefits from this functionality with their user accounts, so must have the appropriate license.
For other features, the line between 'technically possible' and 'indirectly benefits' is blurry. I'll be the first to admit it.
Comments are closed.