Identity Protection in M365

Microsoft Entra ID Protection is a feature of Microsoft Entra ID P2 (formerly Azure AD Premium P2) that automatically detects and responds to identity-based risks. It uses machine learning models and heuristics to identify suspicious activities related to user accounts and sign-ins. The goal is to protect organizations from credential compromise, brute-force attacks, and other identity threats without requiring manual intervention for every alert.

Traditional security relies on static rules and manual review, which is slow and error-prone. Identity Protection provides automated risk detection and remediation, reducing the time between compromise and response. It is part of Microsoft's Zero Trust security model, which assumes breach and continuously validates trust.

Identity Protection operates through three main components:

- Risk Detections: There are over 30 types of risk detections. Key ones for the exam include: - Impossible travel: Two sign-ins from geographically distant locations within a time frame shorter than travel time. Default threshold: 10 minutes. - Anonymous IP address: Sign-in from an IP address classified as anonymous (e.g., Tor, VPN). - Leaked credentials: Credentials found on the dark web. - Malware linked IP address: IP address known to be associated with malware. - Unfamiliar sign-in properties: Sign-in with attributes not seen before for that user. - Suspicious browser: Browser with known security issues. - Risk Levels:

- Low: Confidence > 0% but < 30% - Medium: Confidence 30-60% - High: Confidence > 60% - Policies: Two default policies exist: - User risk policy: Remediate users with high user risk (default: require password change). - Sign-in risk policy: Remediate sign-ins with medium or high sign-in risk (default: require MFA). - Timers: Risk detections are stored for 90 days. User risk is calculated based on detections within a rolling window of 7 days.

Identity Protection is configured in the Microsoft Entra admin center under Protection > Identity Protection. You can create custom Conditional Access policies that use risk as a condition. For example:

- Sign-in risk: High
- Grant: Require multi-factor authentication

To verify risk events, use: - PowerShell: Get-AzureADIdentityProtectionRiskDetections - Graph API: GET /identityProtection/riskDetections

The Risky users report shows users with high risk. The Risky sign-ins report shows sign-in risk events.

Identity Protection integrates with: - Conditional Access: Risk is a condition that can trigger access controls. - Microsoft Defender for Cloud Apps: Provides additional risk signals like impossible travel from app usage. - Microsoft Sentinel: Can ingest risk events for SIEM correlation. - Azure AD Privileged Identity Management (PIM): Risk can affect privileged role activation.

- High user risk → Force password reset - High sign-in risk → Require MFA or block sign-in - False positives: Administrators can dismiss risks or confirm safe/compromised. - Report-only mode: Allows testing policies before enforcement. - Risk feedback: Admins can manually set risk level to influence machine learning.

# Get all risk detections
Get-AzureADIdentityProtectionRiskDetections

# Get risky users
Get-AzureADIdentityProtectionRiskyUser

# Confirm user compromised
Set-AzureADIdentityProtectionRiskyUser -UserId user@domain.com -Action confirmCompromised

A large enterprise with 50,000 users was suffering from credential stuffing attacks. Attackers used leaked passwords from other sites to try to log in. The security team enabled Identity Protection with sign-in risk policies. They configured a Conditional Access policy requiring MFA for any sign-in with Medium or High risk. Within days, thousands of sign-in attempts were blocked or challenged with MFA. The team also created a user risk policy that forced password reset for users with High user risk. This reduced account compromise by 90%. The key was tuning the risk thresholds: they initially set the policy to trigger on Medium risk, but after analyzing false positives, they adjusted to only High risk for blocking, while using MFA for Medium.

A company with a global workforce noticed that some users were signing in from two continents within minutes. Identity Protection flagged these as 'Impossible travel' events. The default threshold of 10 minutes was too sensitive for legitimate users using VPNs. The admin adjusted the policy to require MFA for impossible travel events, rather than blocking. They also created a trusted IP range for corporate VPNs to reduce false positives. Over time, the machine learning adapted to the user's typical travel patterns, reducing false alarms. The security team used the 'Risky sign-ins' report to investigate each event and confirm whether it was a real compromise or a false positive.

A mid-sized organization had several users whose credentials appeared on the dark web. Identity Protection detected these via the 'Leaked credentials' detection and raised user risk to High. The user risk policy automatically required those users to reset their password at next sign-in. The IT team also notified affected users via email. However, some users ignored the prompt, so the admin set the policy to block sign-in until password reset. This ensured compliance. The team also integrated with Microsoft Defender for Cloud Apps to monitor post-reset activity for any lingering compromise.