Microsoft Entra Identity Protection

Microsoft Entra Identity Protection is a cloud-based service that detects, investigates, and remediates identity-based risks. It is part of Microsoft Entra ID (formerly Azure Active Directory) and is available with Azure AD Premium P2 licenses. Identity Protection provides continuous risk detection for user sign-ins and user accounts, leveraging signals from Microsoft's vast telemetry, including trillions of sign-in events daily. It uses machine learning models to identify patterns indicative of compromise, such as credential theft, token replay, and malicious IP addresses.

Traditional security measures like passwords and even multi-factor authentication (MFA) are insufficient against modern attacks such as phishing, password spray, and session hijacking. Identity Protection adds a dynamic risk layer that evaluates each sign-in attempt in real time. It enables organizations to automate responses—for example, requiring MFA only when a sign-in is deemed risky, balancing security and user experience. Without Identity Protection, organizations would have to manually review logs and lack the real-time intelligence to stop attacks as they happen.

Identity Protection operates on two primary risk detection categories: sign-in risk and user risk. Each sign-in attempt is evaluated by the Azure AD authentication pipeline, which sends telemetry to the Identity Protection service. The service processes this telemetry through machine learning models that have been trained on known attack patterns. The output is a risk level: Low, Medium, or High. These risk levels are then used by conditional access policies to trigger automated remediation actions.

Sign-in Risk is the probability that a specific authentication request is not authorized by the legitimate user. It is calculated based on real-time detections and offline detections. Real-time detections include: - Unfamiliar sign-in properties: The sign-in has characteristics not seen before for that user, such as a new IP, device, or location. - Anonymous IP address: The sign-in originates from an anonymous proxy or Tor network. - Atypical travel: Two sign-ins from geographically distant locations within a time period that would be impossible for the user to travel between. - Malware linked IP address: The sign-in IP is associated with known malware activity. - Token issuer anomaly: The token issuer is suspicious.

User Risk is the probability that a user's identity has been compromised. It aggregates risk detections over time, including: - Leaked credentials: The user's credentials have been found on the dark web. - Azure AD threat intelligence: Microsoft's threat intelligence indicates the user is involved in a known attack pattern. - Confirmed compromise: An administrator has confirmed the user is compromised.

Each detection type outputs a risk level. The overall risk level for a sign-in or user is determined by the highest risk level among active detections. For example, if a sign-in has a medium risk from unfamiliar properties and a high risk from anonymous IP, the overall risk is high.

Default risk levels: - Low: No significant risk detected. - Medium: Some suspicious activity, but not definitive. - High: Strong evidence of compromise.

The exact thresholds are proprietary and adjusted by machine learning, but administrators can influence them by setting risk-based conditional access policies. There is no configurable risk score threshold exposed to administrators; only risk levels are used in policies.

To configure Identity Protection, an administrator must have Azure AD Premium P2 licenses assigned to users. The service is enabled by default for all users in the tenant, but risk policies must be created to take action.

Creating a risk-based conditional access policy: 1. Navigate to Azure AD > Security > Identity Protection > Conditional Access policies. 2. Click 'New policy'. 3. Assign users. 4. Under 'Conditions', select 'Sign-in risk' and choose risk levels (Low, Medium, High). 5. Under 'Access controls', choose 'Grant', then select 'Require multi-factor authentication' or 'Block access'. 6. Enable policy and save.

Verification: - Use the 'Risky sign-ins' and 'Risky users' reports in Identity Protection to review detections. - Use PowerShell to query risk detections:

Connect-AzureAD
Get-AzureADIdentityProtectionRiskyUser -All $true
Get-AzureADIdentityProtectionRiskySignIn -All $true

GET https://graph.microsoft.com/beta/identityProtection/riskyUsers
GET https://graph.microsoft.com/beta/identityProtection/riskDetections

Identity Protection integrates with: - Conditional Access: The primary way to automate responses. Policies evaluate sign-in risk and user risk to grant access, require MFA, or block. - Microsoft Defender for Cloud Apps: Session controls and app-level policies can be triggered by risk signals. - Microsoft Sentinel: Risk detections can be ingested as alerts for investigation and correlation with other signals. - Azure AD Identity Governance: User risk can trigger access reviews or automated account remediation. - Microsoft Graph API: Programmatic access to risk data for custom integrations.

Step 1: User attempts to sign in - The user enters credentials on a Microsoft service like Office 365, Azure portal, or a federated app. The authentication request is sent to Azure AD.

Step 2: Azure AD authentication - Azure AD verifies the credentials. If MFA is required by a separate policy, it is enforced before Identity Protection evaluation. Identity Protection evaluates after primary authentication succeeds.

Step 3: Authentication event triggers Identity Protection evaluation - The authentication event is sent to the Identity Protection service asynchronously. Real-time detections are processed within seconds; offline detections may take minutes to hours.

Step 4: Signals collected - Identity Protection collects IP address (geolocation, anonymity status), device fingerprint, user agent, time of day, and historical data for the user. This data is normalized and compared to the user's baseline.

Step 5: Machine learning models analyze signals - Models detect anomalies like impossible travel (two sign-ins from distant locations within short time), unfamiliar sign-in properties (first time from this IP), or anonymous IP (Tor exit node). Each detection type produces a risk level.

Step 6: Risk level assigned - The highest risk level among all detections for that sign-in becomes the overall sign-in risk. For example, if unfamiliar sign-in properties give medium risk and anonymous IP gives high risk, overall sign-in risk is high.

Step 7: Conditional Access policy evaluation - Conditional Access evaluates all policies that include sign-in risk as a condition. If any policy matches the risk level, the policy's access controls are applied. Policies are evaluated in order, and the most restrictive applies.

Step 8: If risk level matches policy condition, policy action enforced - Common actions: require MFA, block access, require password reset (for user risk), or allow with session controls. The user may be prompted for additional verification.

Step 9: Sign-in completed or blocked - If the policy grants access, the user proceeds. If blocked, the user sees an error message. If MFA is required, the user completes MFA.

Step 10: User risk updated - After sign-in, the user's overall risk level is recalculated based on all recent sign-in risks. A high-risk sign-in may elevate the user's risk to medium or high. User risk is used by separate conditional access policies.

Scenario 1: Protecting against password spray attacks

A large enterprise with 50,000 users faces password spray attacks where attackers try common passwords against many accounts. Identity Protection detects multiple failed sign-ins from a single IP address and flags the IP as malicious. When a legitimate user later signs in from that IP (if it's a shared corporate proxy), the sign-in may be flagged as medium risk due to malware linked IP. The administrator configures a conditional access policy to require MFA for medium or high sign-in risk. This blocks the attacker's attempts (since they don't have MFA) while allowing legitimate users to authenticate via MFA. The organization uses Azure AD Premium P2 licenses for all users and reviews risky sign-ins weekly. A common issue is false positives from corporate VPNs that use IP addresses known to be anonymous. To mitigate, the administrator adds the VPN IP ranges to a trusted IP list in Azure AD, which reduces risk for those sign-ins.

Scenario 2: Responding to leaked credentials

A mid-sized company discovers that employee credentials were exposed in a third-party data breach. Identity Protection's leaked credentials detection identifies affected users within hours. The administrator creates a conditional access policy that requires password reset for users with high user risk. When the affected users sign in, they are prompted to change their password. The administrator also uses the 'Risky users' report to manually confirm compromised users and force a password reset. The company has a process to notify users via email. A common pitfall is that users may ignore the password reset prompt if they can dismiss it, so the policy should be set to block access until password reset is completed.

Scenario 3: Detecting impossible travel

A global organization with employees traveling frequently uses Identity Protection to detect token theft. An attacker in another country steals a user's token and attempts to sign in from a location far from the user's current location. Identity Protection detects two sign-ins within minutes that are geographically impossible (e.g., New York and London). The sign-in risk is set to high. A conditional access policy blocks high-risk sign-ins. The legitimate user is unaffected because their sign-in from New York was already authenticated. The attacker is blocked. The administrator configures an exception for known corporate travel patterns by excluding certain IP ranges or using named locations. Overblocking can occur if users use VPNs that route through different countries; administrators must adjust policies accordingly.

Exactly What SC-900 Tests

Objective 2.5: Describe the capabilities of Microsoft Entra Identity Protection. The exam expects you to:

Common Wrong Answers

Specific Numbers and Terms

Edge Cases

How to Eliminate Wrong Answers

1. Myth: Identity Protection is a separate Azure service that requires additional configuration. Reality: Identity Protection is built into Azure AD Premium P2 and is enabled by default for all users in the tenant. However, risk policies must be configured to take action.

2. Myth: Risk levels are based on a single detection type. Reality: The overall risk level for a sign-in or user is determined by the highest risk level among all active detections. Multiple detections can contribute.

3. Myth: Identity Protection can prevent all identity-based attacks. Reality: Identity Protection reduces risk but cannot prevent all attacks. It relies on signals and machine learning; some attacks may not be detected, especially if they mimic normal behavior.

4. Myth: User risk is only updated when a user signs in. Reality: User risk is updated periodically (every 1-2 hours) based on new sign-in risk detections and offline detections like leaked credentials.

5. Myth: Identity Protection works without Conditional Access. Reality: Identity Protection detects risk, but actions are enforced through Conditional Access policies. Without policies, risk is only reported, not acted upon.

| Feature | Sign-in Risk | User Risk | |---------|--------------|-----------| | Scope | Per authentication event | Aggregated over time for a user | | Detection examples | Unfamiliar sign-in properties, anonymous IP, atypical travel | Leaked credentials, confirmed compromise | | Typical response | Require MFA, block access | Force password reset | | Update frequency | Real-time for some detections, offline for others | Every 1-2 hours | | Retention | 90 days | 90 days |

1. Q: What license is required for Microsoft Entra Identity Protection? A: Azure AD Premium P2. This license includes Identity Protection, Conditional Access, and other advanced features. Premium P1 includes Conditional Access but not Identity Protection.

2. Q: What is the difference between sign-in risk and user risk? A: Sign-in risk is evaluated per authentication attempt and reflects the likelihood that the sign-in is unauthorized. User risk is an aggregate of all risk detections for a user over time, indicating whether the user's identity may be compromised. User risk is updated every 1-2 hours.

3. Q: Can Identity Protection automatically block a sign-in? A: Yes, if a Conditional Access policy is configured to block access for a specific sign-in risk level. Identity Protection itself only detects risk; Conditional Access enforces the action.

4. Q: How long are risk detections retained? A: Risk detections are retained for 90 days. After that, they are removed from the reports.

5. Q: What are the common risk detection types? A: Unfamiliar sign-in properties, anonymous IP address, atypical travel, malware linked IP address, leaked credentials, and Azure AD threat intelligence.

6. Q: Can I customize risk levels? A: No, risk levels (Low, Medium, High) are determined by Microsoft's machine learning models and cannot be customized. However, you can choose which risk levels to act on in Conditional Access policies.

7. Q: Does Identity Protection work for on-premises identities? A: Yes, if you sync on-premises AD with Azure AD using Azure AD Connect. Risk detections apply to synced users as well.

1. Question: Which license is required to use Microsoft Entra Identity Protection? A. Azure AD Free B. Azure AD Premium P1 C. Azure AD Premium P2 D. Office 365 E3 Answer: C. Azure AD Premium P2. Identity Protection is a Premium P2 feature; Premium P1 includes Conditional Access but not Identity Protection.

2. Question: What risk level indicates strong evidence of compromise? A. Low B. Medium C. High D. Critical Answer: C. High. Risk levels are Low, Medium, and High. There is no 'Critical' level.

3. Question: Which action is appropriate for a user with high user risk? A. Require MFA at next sign-in B. Block all sign-ins C. Force password reset D. Allow access and monitor Answer: C. Force password reset. High user risk indicates the user may be compromised; resetting the password secures the account.

4. Question: Which detection type is an example of sign-in risk? A. Leaked credentials B. Unfamiliar sign-in properties C. Administrator confirmed compromise D. Azure AD threat intelligence Answer: B. Unfamiliar sign-in properties is a sign-in risk detection. Leaked credentials and confirmed compromise are user risk detections.

5. Question: How often is user risk updated? A. Real-time B. Every 30 minutes C. Every 1-2 hours D. Daily Answer: C. Every 1-2 hours. User risk is recalculated periodically based on new sign-in risk detections and offline detections.

A multinational corporation with 100,000 users deploys Identity Protection to combat credential theft. They configure a conditional access policy that requires MFA for medium and high sign-in risk. The policy excludes a set of emergency break-glass accounts. In production, they observe that some legitimate users are prompted for MFA when traveling, which is acceptable. However, they also notice false positives from their corporate VPN, which uses IP addresses that sometimes appear on anonymous IP lists. To reduce false positives, they add the VPN's public IP ranges to Azure AD's named locations and mark them as trusted. This reduces the risk level for sign-ins originating from those IPs. They also create a policy for user risk: if user risk is high, the user must change their password at next sign-in. This policy automatically remediates accounts with leaked credentials. The organization reviews the risky users report weekly and manually investigates accounts with repeated high-risk events. A common issue is that users may ignore the password reset prompt if they can dismiss it; to enforce remediation, the policy is set to block access until password reset is completed. Performance is not a concern because Identity Protection scales automatically with the tenant size.

A medium-sized company (5,000 users) learns that employee credentials were exposed in a third-party breach. Identity Protection's leaked credentials detection identifies 200 affected users within hours. The administrator immediately creates a conditional access policy that blocks sign-ins for users with high user risk, except for a few IT admins who are allowed with MFA. The affected users are unable to sign in and receive instructions to contact IT. The administrator then uses the 'Risky users' report to bulk dismiss risk for users who have changed their passwords manually, and forces password reset for others. The company also enables self-service password reset (SSPR) to allow users to reset passwords without IT intervention. A common misconfiguration is not excluding emergency access accounts, which could lock out administrators. The organization also configures alerts to notify the security team when a user risk level changes to high. They use Microsoft Graph API to pull risk data into their SIEM for correlation with other events. The entire remediation process takes less than a day, minimizing the impact of the breach.

A financial services firm with strict security requirements uses Identity Protection to detect token theft. An attacker steals a user's session token and attempts to sign in from a different country while the user is active in the office. Identity Protection's impossible travel detection flags the second sign-in as high risk because the two sign-ins occurred within 5 minutes from locations 3,000 miles apart. The conditional access policy blocks high-risk sign-ins, preventing the attacker from accessing data. The legitimate user is unaffected. To avoid false positives from users who use VPNs that route through different countries, the firm adds its VPN IP ranges to trusted named locations and configures the impossible travel detection to ignore sign-ins from trusted IPs. They also create an exception for executives who travel frequently by using a separate conditional access policy that only requires MFA instead of blocking. The firm reviews the risky sign-ins report daily and investigates any blocked sign-ins that might be false positives. Over time, they fine-tune policies to balance security and usability.

Identity Protection processes trillions of sign-in events globally. For a single tenant, there is no performance impact because evaluation is asynchronous and does not delay authentication. However, administrators should be aware that risk reports may take a few minutes to update after a sign-in. There are no capacity limits, but the number of risk detections may be large in a tenant with many users. Reports can be filtered and exported. The service uses machine learning that improves over time as more data is collected, so new tenants may experience more false positives initially.