Detection: Defender for Identity and Identity Protection

Lab Metadata

Core technologies

Scenario and Description

Labs 01 to 09 raised the walls: strong authentication, enforced MFA, phishing-resistant keys, just-in-time privilege, clean hygiene and a hardened hybrid bridge. A mature programme accepts that walls are eventually breached and builds the second half of the picture, detection and response. This is the "assume breach" pillar of Zero Trust, and it is where the brief's Defender for Identity and Zero Trust requirements live.

Two Microsoft capabilities cover the identity attack surface. Microsoft Entra ID Protection watches cloud sign-ins and accounts, scoring each for risk: leaked credentials (surfaced because you enabled Password Hash Sync in Lab 09), impossible travel, anonymous IP addresses, unfamiliar sign-in properties and more. Those risk scores can drive Conditional Access in real time, demanding MFA on a risky sign-in or a secure password change on a risky user. Microsoft Defender for Identity watches the on-premises side, sensors on your domain controllers and other identity servers detect reconnaissance, DCSync, Golden Ticket, Pass-the-Hash and lateral movement, exactly the techniques the Lab 09 hardening aims to prevent.

You will read the tenant's current risk state from Graph, build risk-based Conditional Access policies in report-only, walk the risk remediation flow, then plan and understand a Defender for Identity deployment and its Identity Security Posture recommendations, which will point straight back at the hardening you did in Lab 09.

Prerequisites

Prior labs

Labs 01, 03, 05 and 09 recommended. Risk-based Conditional Access builds on the policy and break-glass patterns from Lab 03, user-risk password change relies on SSPR from Lab 05, and leaked-credential detection depends on Password Hash Sync from Lab 09. ID Protection requires Entra ID P2 (your trial). Defender for Identity requires its own licence, covered by a Microsoft 365 E5 trial.

Graph scopes introduced

Real-World Problem Statement

Static controls treat every sign-in the same. But a sign-in from a user whose password just appeared in a breach dump, from an anonymous proxy, in a country they have never visited, is not the same as their normal morning login. Detection turns those differences into signals, and risk-based access turns signals into proportionate, automatic responses. Without it, you either over-challenge everyone or miss the sign-ins that matter.

Concrete scenario: Northgate wants leaked-credential and impossible-travel sign-ins challenged automatically, high-risk users forced through a secure password reset, and its domain controllers watched for DCSync and Golden Ticket activity, with alerts flowing to the security team in one portal.

Skills Mapped to Production Solutions

Architecture Overview

Two detection engines cover the two halves of identity. ID Protection scores cloud sign-ins and users, feeding Conditional Access. Defender for Identity sensors watch on-premises identity servers. Both surface in the Microsoft Defender XDR portal for a single view.

Step-by-Step Implementation

Phase A - Read the current risk state

Connect-MgGraph -Scopes 'IdentityRiskyUser.Read.All','IdentityRiskEvent.Read.All',
  'Policy.ReadWrite.ConditionalAccess','Directory.Read.All' -NoWelcome

# Current risky users, highest risk first.
Get-MgRiskyUser -All |
  Select-Object UserPrincipalName, RiskLevel, RiskState, RiskLastUpdatedDateTime |
  Sort-Object RiskLevel -Descending | Format-Table -AutoSize

# Individual risk detections (the events behind the scores).
Get-MgRiskDetection -Top 20 |
  Select-Object UserPrincipalName, RiskEventType, RiskLevel, DetectedDateTime, IpAddress |
  Format-Table -AutoSize

Phase B - Risk-based Conditional Access

# Reuse the break-glass exclusion group from Lab 03.
$bg = Get-MgGroup -Filter "displayName eq 'CA-Exclude-BreakGlass'"

# CA003: require MFA when the SIGN-IN is medium or high risk.
$signInRisk = @{
  displayName = 'CA003 - Require MFA on sign-in risk'
  state = 'enabledForReportingButNotEnforced'
  conditions = @{
    users = @{ includeUsers = @('All'); excludeGroups = @($bg.Id) }
    applications = @{ includeApplications = @('All') }
    signInRiskLevels = @('high','medium')
  }
  grantControls = @{ operator = 'OR'; builtInControls = @('mfa') }
}
$ca003 = New-MgIdentityConditionalAccessPolicy -BodyParameter $signInRisk

# CA004: require MFA + secure password change when the USER is high risk.
# passwordChange needs SSPR enabled (Lab 05) and works for cloud/synced users.
$userRisk = @{
  displayName = 'CA004 - Secure password change on high user risk'
  state = 'enabledForReportingButNotEnforced'
  conditions = @{
    users = @{ includeUsers = @('All'); excludeGroups = @($bg.Id) }
    applications = @{ includeApplications = @('All') }
    userRiskLevels = @('high')
  }
  grantControls = @{ operator = 'AND'; builtInControls = @('mfa','passwordChange') }
}
$ca004 = New-MgIdentityConditionalAccessPolicy -BodyParameter $userRisk

Phase C - The remediation flow

# SELF-REMEDIATION (preferred, automatic):
#  - Sign-in risk: the user completing MFA on the risky sign-in clears it.
#  - User risk: the user performing a secure password change (via SSPR)
#    clears the user risk. CA004 drives exactly this.
#
# ADMIN REMEDIATION (manual, in the Entra / Defender portal or via Graph):
#  - Confirm compromised: raises the user to high risk, forcing remediation.
#  - Dismiss risk: clears risk you have investigated and deem safe.
#  - Confirm safe: marks a detection as a false positive to tune the model.
#
# Example: confirm a user compromised via Graph (investigate first).
# $u = Get-MgUser -Filter "userPrincipalName eq 'suspect@contoso.com'"
# Confirm-MgRiskyUserCompromised -BodyParameter @{ userIds = @($u.Id) }
# Dismissal and confirm-safe are available in the portal and via the
# riskyUsers dismiss action.

Phase D - Defender for Identity on the on-premises side

# DEPLOYMENT (Microsoft Defender portal: security.microsoft.com):
#  1. Settings > Identities: the workspace is created automatically.
#  2. Configure a Directory Service account (a gMSA is recommended) so the
#     sensor can query AD.
#  3. Download the sensor package and its access key.
#  4. Install the sensor on each domain controller, and on AD CS, AD FS and
#     the Entra Connect server where present.
#  5. Sensors auto-update and stream to Defender XDR, no port mirroring needed.
#
# WHAT IT DETECTS (mapped to attacks from earlier labs):
#  - Suspected DCSync attack        -> the sync-account risk from Lab 09
#  - Golden Ticket / forged tickets -> Kerberos abuse
#  - Pass-the-Hash / Pass-the-Ticket / Overpass-the-Hash
#  - Reconnaissance and enumeration (LDAP, SMB, account probing)
#  - Suspected brute force, AS-REP roasting, Kerberoasting
#  - Lateral movement paths to sensitive accounts

Phase E - Tie it together as Zero Trust

# VERIFY EXPLICITLY
#  - MFA and phishing-resistant auth (Labs 02-04)
#  - Risk-based Conditional Access using real-time signals (this lab)
#
# USE LEAST-PRIVILEGE ACCESS
#  - Just-in-time PIM activation (Lab 07)
#  - Access reviews and hygiene (Lab 08)
#
# ASSUME BREACH
#  - Detection with ID Protection and Defender for Identity (this lab)
#  - Hardened, monitored hybrid bridge (Lab 09)
#  - Automated response: risk remediation, account disablement (Lab 06)

Testing and Validation

1. Risk read: run Phase A and confirm you can pull risky users and detections.
2. Policies: confirm CA003 and CA004 exist in report-only, excluding break-glass.
3. Simulated risk: sign in through an anonymous VPN or Tor to generate a sign-in risk detection, then observe the report-only result in the sign-in logs.
4. Self-remediation: as a test user marked at risk, confirm a secure password change clears user risk.
5. Defender for Identity: if you have a lab DC, install a sensor and confirm it reports healthy in the Defender portal.

Security Analysis

What makes this sound

• Adaptive response: friction falls on risky sign-ins, not everyone, improving both security and experience.
• Self-healing: user-risk remediation resolves most credential compromise automatically, with a full record.
• Two-sided coverage: ID Protection watches the cloud, Defender for Identity watches on-premises, together they cover the identity kill chain.
• Posture feedback: Defender for Identity assessments continuously point at concrete hardening, closing the loop with Lab 09.

Intentionally simplified for the lab

• Sensor deployment is planned, not performed, without a lab domain, the cloud risk work is the hands-on portion.
• Risk policies are left in report-only, real enforcement follows the validated flip from Lab 03.

Production hardening

• Integrate risk detections and Defender alerts into your SIEM or SOC workflow for triage and response.
• Tune risk thresholds to your tolerance, and review confirmed-safe detections to keep the model honest.
• Track the Identity Security Posture score as a programme metric alongside Secure Score (Lab 12).

Cleanup Instructions

foreach ($name in 'CA003 - Require MFA on sign-in risk','CA004 - Secure password change on high user risk') {
  $p = Get-MgIdentityConditionalAccessPolicy -Filter "displayName eq '$name'"
  if ($p) { Remove-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $p.Id }
}
Disconnect-MgGraph

Recommended Learning Links

• Microsoft Entra ID Protection overview
• Risk-based access policies
• Remediate and unblock risky users
• Microsoft Defender for Identity
• Deploy Defender for Identity sensors
• Zero Trust identity

Key Takeaways and Next Lab

• Assume breach: prevention is paired with detection and automatic, proportionate response.
• ID Protection turns real-time risk into Conditional Access, favouring self-remediation.
• Defender for Identity watches the on-premises servers you hardened, detecting DCSync, Golden Ticket and lateral movement.
• Its posture assessments feed straight back into the hardening from Lab 09, closing the loop.