Lab 3. Identity Protection and risk-based access

Time 20 minutes

Admin account lab-adminNN@aurnis.dev

User account lab-userNN@aurnis.dev

Roles Security Operator, Security Reader

Scenario

Identity security is a team sport. Microsoft Entra ID Protection scores every user and sign-in for risk using signals from Microsoft Defender, leaked-credential feeds and behaviour analytics, and Conditional Access acts on that score automatically, before a human in the SOC has opened the alert. Today the SOC has confirmed that a batch of Contoso accounts, including yours, appeared in a credential dump. You will see what the user experiences, investigate as the security operator, and remediate.

Objectives

• Read the tenant's two risk-based Conditional Access policies
• Experience a user-risk block as the user
• Investigate the risky user and the detection that caused it
• Remediate the user and confirm access is restored
• Optionally, find the matching alert in Microsoft Defender XDR

Instructor note

At the start of this lab the instructor marks every lab user as compromised (Identity Protection, confirm compromised, through Microsoft Graph). This raises each user's risk level to High deterministically. Do not start Task 2 until the instructor says the users are flagged.

Task 1. Read the risk policies

Admin window

1. In the left menu select Protection Conditional Access Policies.
2. In the search box above the list type BASE-. Two policies remain: BASE-User-risk-Block and BASE-Sign-in-risk-MFA.
3. Select BASE-User-risk-Block (read only, change nothing). Note:
   • Users: the group Lab-Users-All, with the admins and the break-glass account excluded.
   • Target resources: All resources.
   • Conditions, User risk: High.
   • Grant: Block access.
4. Select the X at the top right to close it without saving.
5. Select BASE-Sign-in-risk-MFA. Note:
   • Conditions, Sign-in risk: High and Medium.
   • Grant: Require multifactor authentication.
   • Session: Sign-in frequency, Every time.
6. Close it without saving.

BASE-User-risk-Block: user risk High leads to Block access.

Expected result

You can state in one line what happens to a high-risk user and to a medium-risk sign-in in this tenant. Note the difference: user risk is about the account, sign-in risk is about one particular sign-in attempt.

I finished Task 1

Task 2. Experience the block as the user

User window

Wait for the instructor to announce that the lab users are flagged.

1. In the User window sign out (account picture, Sign out), close the window, and open a fresh one.
2. Go to https://www.microsoft365.com.
3. Type lab-userNN@aurnis.dev and sign in with your passkey (or password plus push if you used the Temporary Access Pass in Lab 2).

The user is refused because the account, not the sign-in, is considered compromised.

Expected result

A page saying Your account is blocked (or You cannot access this right now) that mentions your organisation's security policy. Nothing you did was wrong; the account is treated as compromised, so every sign-in is refused until someone remediates.

Wait for propagation

If you still get in, the risk flag has not reached your session yet. Wait one minute and try again in a fresh window.

I finished Task 2

Task 3. Investigate as the security operator

Admin window

1. In the left menu select Protection Identity Protection.
2. Read the Dashboard tiles: users at risk, sign-ins at risk, detections in the last period.
3. Under Report select Risky users.
4. In the search box type lab-userNN and select the row.

Risky users: your lab user at High risk, state Confirmed compromised.

5. In the details panel read Risk level: High and Risk state: Confirmed compromised.
6. Select the Risk history tab. Note the detection Admin confirmed user compromised and its time. In a real incident you would see detections such as Leaked credentials, Anonymous IP address or Atypical travel here.
7. Under Report select Risky sign-ins.
8. Find your blocked attempt from Task 2 (filter on User if needed) and select it.
9. Select the Conditional Access tab.

The blocked sign-in is attributed to BASE-User-risk-Block.

Expected result

The user is High risk, the detection is named, and the block is attributed to BASE-User-risk-Block with result Failure.

I finished Task 3

Task 4. Remediate and confirm access is restored

Admin window

1. Go back to Risky users and select lab-userNN again.
2. At the top of the details panel select Dismiss user risk. (In production you would usually choose Reset password or let a Conditional Access policy force a secure password change; today the pod has investigated and is satisfied.)
3. Confirm with Yes (or Dismiss).

Dismiss user risk clears the state to Dismissed and the level to None.

4. Select Refresh. Risk state now reads Dismissed and Risk level reads None.
5. User window Sign out, open a fresh window, and sign in again at https://www.microsoft365.com.

Expected result

Sign-in succeeds. In the Admin window the newest sign-in log entry (Identity, Monitoring & health, Sign-in logs) shows BASE-User-risk-Block as Not applied because the user-risk condition no longer matches.

I finished Task 4

Task 5 (optional). Find the alert in Microsoft Defender XDR

Admin window

1. Open a new tab and go to https://security.microsoft.com.
2. In the left menu select Incidents & alerts Alerts.
3. Look for an alert about lab-userNN, for example Admin confirmed user compromised or User at risk, from the source Microsoft Entra ID Protection.

Expected result

The identity risk appears in the same alert queue the SOC uses for endpoint and email alerts. Investigation and response happen in one place.

I finished Task 5

Reflection

• The user was blocked before any analyst looked at the alert. What is the trade-off between that automatic response and the help-desk load it can create?
• Which risk detections would you set to Block and which to Require MFA or Require password change in your own tenant?
• With Copilot deployed, what could an attacker who owns this account ask for in the first five minutes?

Checklist

• Both BASE- risk policies read and understood
• Blocked as the user while at High risk
• Detection found in Risk history and block attributed to the right policy
• User risk dismissed and sign-in restored
• (Optional) Alert found in Defender XDR

Next: Lab 4: Compliant device access.