Azure AD Identity Protection is one of the security tools available in the Microsoft E5 license. With Azure AD Identity Protection it is possible to protect users based on the Microsoft signals.  Azure AD Identity protection is all about risk, detection, and remediation based on the identity level. Microsoft uses threat intelligence to specify risky detection for all users.  This blog is about all the parts of Azure AD Identity Protection. 

Blog is published: July 12,2021 (information can be outdated)

What is Azure AD Identity Protection?

For several years Azure AD Identity Protection is available with the Azure AD P2 license. Azure AD Identity Protection gives the following key tasks for organizations:

  • Automate detection and remediation for identity risk events
  • Investigate risk
  • Protect users automatically based on risk

Identity Protection uses the threat intelligence information from AzureAD and all the threat intelligence information from customers worldwide. Based on the analyzed events Microsoft protects users from threats.

Two main risk detection components are part of the Azure AD Identity Protection solution:

  • Sign-in risk
  • User-risk

User Risk

A user risk represents the probability that a given identity or account is compromised. The user risk detections are calculated offline using the Microsoft internal and external intelligence feed.

  • Leaked credentials
  • Azure AD threat intelligence

Sign-in Risk

A sign-in risk represents the probability that a given authentication request isn’t authorized by the identity owner. Examples for sign-in risk:

  • Anonymous IP address
  • Atypical travel
  • Malware linked IP address
  • Unfamiliar sign-in properties
  • Leaked credentials
  • Password spray

Risk can be calculated in real-time or offline using threat intelligence. More sign-in risk scenarios, later in the blog.

Requirements

For all the functionality functions, an Azure AD Premium P2 license is necessary. Azure AD Premium P2 is needed for all the Identity Protection features.

Configure Azure AD Identity Protection

For Azure AD Identity Protection, multiple policies should be enabled to use the full capabilities of Identity Protection. Keep in mind that there will be user impact.

User-risk policy

Enabling this policy will have an impact on the users that are flagged as risky. Always start small with a pilot group and audit first.

  1. Sign in to your Azure Portal
  2. Go to Azure AD Identity Protection 
  3. Click under protection on the User risk policy (1) to start configuring
  4. Assign the policy to all users or a selected group (2) and optionally exclude break-glass accounts
  5. Click User risk (3) and select the user risk level. Microsoft’s recommendation is to set the user risk policy threshold to High. It is always possible to test medium and above and report the impact for the medium policy. 
  6. Click Controls (3) and be sure to check Allow Access, Require password change (4) With this access is possible after a required password change for the user. 
  7. Enforce the policy for the activation

Sign-in risk policy

Enabling this policy will have an impact on the users that are flagged as risky. Always start small with a pilot group and audit first.

  1. Sign in to your Azure Portal
  2. Go to Azure AD Identity Protection 
  3. Click under protection on the Sign-in risk policy (6) to start configuring
  4. Assign the policy to all users or a selected group (7) and optionally exclude break-glass accounts
  5. Click User risk(8) and select the medium and above level. Microsoft’s recommendation is to set the user risk policy threshold to medium and above. It is always possible to test medium and above and report the impact for the medium policy.
  6. Click Controls (9) and be sure to check Allow Access, Require multi-factor authentication(10) With this access is possible after a required MFA authentication for the user.
  7. Enforce the policy for the activation

Now the sign-in risk policy and user risk policy are configured. The next part; notifications.

Notifications

It’s advisable to review the risky users and sign in frequently to optimize the impact and detect possible changes for the sign-in risk level. From the Defender for Identity portal, it is possible to configure some notifications based on a risk level.

For configuring the notifications:

  1. Under notify, click; User at risk detected alerts
  2. Add the users or custom email addresses
  3. It is possible to alert based on the user risk level. For now only high is selected and part of the alerting scope.

Weekly email digest

The weekly email digest can help you to review the risky every week and gives also a weekly overview. For configuring the weekly email digest; click notify – Weekly digest

Portal overview

Once opened the Identity Protection page. The portal gives a summary overview of the new risky user detected and sign-in risk detection. Keep in mind, my demo tenant contains limited users and the data is limited in the overview dashboard.

Report

Under reports, we can find advanced reports on risky users, risky sign-ins, and risk detections with all the available information. The report blade is available for the following views:

  • Risky users: Overview risky users
  • Risky sign-ins: Specific risky sign-in information
  • Risk detections: Type of risk detected

From the reports view,  you have the option to click for more details and some actions. Actions available:

  • Reset password
  • Confirm user compromised
  • Dismiss user risk
  • Block user
  • Investigate with Azure ATP
  • Confirm sign-in safe

From the risky sign-ins screen it is possible to use a couple of useful filters. For example; detection type(s) and the selected risk level real-time status.

From the details info field, you have the option to view the Device info, Risk info, MFA info. Interesting is the Risk info detection type field: In this case, the Tor sign-in is based on the risk detection: Anonymous IP address.

Live demo

For this demo, a policy is created and signed in from a tor browser network. Suspicious activity is detected. To verify the sign-in use the verify button from the screen:

Sign-in risk with the Sign-in risk policy block access control configured:

Continuous Access Evaluation (CAE)

Make sure to enable Access Evaluation (CAE) for direct actions. For the CAE part, read the Continuous Acces Evaluation blogpost with all the details included.

CAE enabled experience:

Good to know

Feedback to the system is possible if the user sign-in is safe. Good to know the difference between confirm safe and dismiss user risk.

Selecting confirm safe on a sign-in does not by itself prevent future sign-ins with the same properties from being flagged as risky. The best way to train the system to learn a user’s properties is to use the risky sign-in policy with MFA. When risky sign-ins are prompted for MFA and the user successfully responds to the request, the sign-in can succeed and help to train the system on the legitimate user’s behavior.

If you believe the user is not compromised, use Dismiss user risk on the user level instead of using Confirmed safe on the sign-in level. A Dismiss user risk on the user level closes the user risk and all past risky sign-ins and risk detections.

Leaked credentials? What is it

Leaked credentials are based on multiple places, including the following places. For example the following places are including:

  • Public sites as Pastebin and paste.ca.
  • Law enforcement agencies
  • Dark web research

For the leaked credential risk events make sure you have Password Hash synchronization enabled.

Sign-in risk

For all the information about the Sign-in risk detection inside the Azure AD identity protection view. Source:  Microsoft.com

Risk detection Description
Anonymous IP address Real-time This risk detection type indicates sign-ins from an anonymous IP address (for example, Tor browser or anonymous VPN). These IP addresses are typically used by actors who want to hide their login telemetry (IP address, location, device, etc.) for potentially malicious intent.
Atypical travel Offline This risk detection type identifies two sign-ins originating from geographically distant locations, where at least one of the locations may also be atypical for the user, given past behavior. Among several other factors, this machine learning algorithm takes into account the time between the two sign-ins and the time it would have taken for the user to travel from the first location to the second, indicating that a different user is using the same credentials.

The algorithm ignores obvious “false positives” contributing to the impossible travel conditions, such as VPNs and locations regularly used by other users in the organization. The system has an initial learning period of the earliest of 14 days or 10 logins, during which it learns a new user’s sign-in behavior.
Malware linked IP address Offline This risk detection type indicates sign-ins from IP addresses infected with malware that is known to actively communicate with a bot server. This detection is determined by correlating IP addresses of the user’s device against IP addresses that were in contact with a bot server while the bot server was active.
Unfamiliar sign-in properties Real-time This risk detection type considers past sign-in history (IP, Latitude / Longitude and ASN) to look for anomalous sign-ins. The system stores information about previous locations used by a user, and considers these “familiar” locations. The risk detection is triggered when the sign-in occurs from a location that’s not already in the list of familiar locations. Newly created users will be in “learning mode” for a period of time in which unfamiliar sign-in properties risk detections will be turned off while our algorithms learn the user’s behavior. The learning mode duration is dynamic and depends on how much time it takes the algorithm to gather enough information about the user’s sign-in patterns. The minimum duration is five days. A user can go back into learning mode after a long period of inactivity. The system also ignores sign-ins from familiar devices, and locations that are geographically close to a familiar location.

We also run this detection for basic authentication (or legacy protocols). Because these protocols do not have modern properties such as client ID, there is limited telemetry to reduce false positives. We recommend our customers to move to modern authentication.
Admin confirmed user compromised Offline This detection indicates an admin has selected ‘Confirm user compromised’ in the Risky users UI or using riskyUsers API. To see which admin has confirmed this user compromised, check the user’s risk history (via UI or API).
Malicious IP address Offline This detection indicates sign-in from a malicious IP address. An IP address is considered malicious based on high failure rates because of invalid credentials received from the IP address or other IP reputation sources.
Suspicious inbox manipulation rules Offline This detection is discovered by Microsoft Cloud App Security (MCAS). This detection profiles your environment and triggers alerts when suspicious rules that delete or move messages or folders are set on a user’s inbox. This detection may indicate that the user’s account is compromised, that messages are being intentionally hidden, and that the mailbox is being used to distribute spam or malware in your organization.
Password spray Offline A password spray attack is where multiple usernames are attacked using common passwords in a unified brute force manner to gain unauthorized access. This risk detection is triggered when a password spray attack has been performed.
Impossible travel Offline This detection is discovered by Microsoft Cloud App Security (MCAS). This detection identifies two user activities (is a single or multiple sessions) originating from geographically distant locations within a time period shorter than the time it would have taken the user to travel from the first location to the second, indicating that a different user is using the same credentials.
New country Offline This detection is discovered by Microsoft Cloud App Security (MCAS). This detection considers past activity locations to determine new and infrequent locations. The anomaly detection engine stores information about previous locations used by users in the organization.
Activity from anonymous IP address Offline This detection is discovered by Microsoft Cloud App Security (MCAS). This detection identifies that users were active from an IP address that has been identified as an anonymous proxy IP address.
Suspicious inbox forwarding Offline This detection is discovered by Microsoft Cloud App Security (MCAS). This detection looks for suspicious email forwarding rules, for example, if a user created an inbox rule that forwards a copy of all emails to an external address.

Sources:

Azure AD Identity Protection documentation

Azure AD Identity Protection: What is risk