Entra ID Protection - chadmcox/Azure_Active_Directory GitHub Wiki

Identity Protection

Notes

Clear all old user risk prior to enabling any user risk based policy:

  • Scripts I wrote to help with this
  • Old user risk could lead to unexpected behavior when users signs-in. Ideally all low and medium risk will be cleaned up via script and all high should be reviewed and manually remediated.
  • Starting March 31st, 2024, all "low" risk detections and users in Microsoft Entra ID Identity Protection that are older than 6 months will be automatically aged out and dismissed. This will allow customers to focus on more relevant risk and provide a cleaner investigation environment.

Make sure all trusted networks have been identified and created in a trusted name location

When using federated authentication it is possible to leverage multifactor authentication (supported by Okta, Ping, ADFS and others) to remediate sign-in risk.

To self remediate sign-in risk

  • For cloud authentication user must be registered for Azure MFA
  • Review Workbook - Impact analysis of risk-based access policies / Risky sign-ins remediated by multifactor authentication - shows users that remediated a sign-in risk by providing MFA.

To self remediate user risk

  • Self service password reset and password write back need to be enabled for either cloud authentication or federated authentication.
  • Review Workbook - Impact analysis of risk-based access policies / User risk remediated by password reset - shows if any users have changed password that reset a user risk
  • MFA does not remediate user risk and could make it so that users are prompted over and over. Consider using a block over requiring MFA.

Things you should know!!

  • Do not combine user risk policies and sign-in risk policy into the same risk based conditional access policy.
  • When combined it is not an or its and, which means both risk types have to be meet.
  • MFA will not remediate a user risk, the user will probably get bombarded with prompts.
  • Password change will not remediate a sign-in risk

Identity protection recommended configuration

Legacy identity protection policies

  • User risk policy - should be Disabled
  • Sign-in risk policy - should be Disabled

These are set to retire according to article May 2024 will no longer be able to enable and by July 2024 will no longer be able to modify. April's what's new to Entra Id

Migrate risk policies to Conditional Access

Identity protection MFA registration policy

  • Assignments
    • Include: All Users
    • Exclude: Breakglass, Exclusion Group
  • Controls
    • Require Azure AD MFA registration
  • Enforce policy: On

Identity protection users at risk detected alerts

  • Add users that need to be notified
  • Alert on user risk level at or above: Recommended High

Identity protection weekly digest

  • Add users that need to be notified
  • Send weekly digest emails: Yes

Identity protection settings

This is something you should use if you have password hash sync enable, included for federated authentication.

Workbook - Impact analysis of risk-based access policies

  • Requires Entra ID logs to be integrated with log analytics.
  • This workbook provides information based on successful sign-ins for specific scenarios.
  • Provides who is not being protected by a RBCA.
  • Provides information about remediation or block results from potential RBCA.
  • Provides untrusted networks that are being accessed by multiple users.

Recommended risk based conditional access policies

This is my current set of recommended risk based conditional access policies. I have written several KQL queries to run in either the log analytics attached to Entra ID or Defender XDR. These queries will help make decisions on certain policies.

High user risk require password change

  • Use when self service password reset and password write back is enabled on Entra ID tenant. Including in federation environments
  • Should only be allowed from trusted or compliant devices.
  • User must be registered and enabled for sspr or they are blocked.
  • Recommended by CIS
  • Common Conditional Access policy: User risk-based password change
Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: BreakGlass		 Include: All Cloud Apps User Risk: high Require password change Sign-in frequency: Every time

Review Workbook - Impact analysis of risk-based access policies

  • Impact summary of recommended risk-based access policies / High risk users not prompted for password change - Shows the number of users not being prompted to change password with a RBCA.
  • Impact details: User risk scenarios / High risk users not being prompted to change password by risk-based access policy - shows list of users that would have been impacted if a RBCA was in place

High user risk block all cloud apps when using untrusted or not compliant devices

  • Should be used when leveraging the require password change policy. This policy will make sure users not on trusted or compliant devices will be blocked from changing their password.
  • Requires for someone to research and respond to high users risk as they come in. (Usually Security Operations)
  • Allow on-premises password change to reset user risk will help with user risk clean up.
Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: BreakGlass		 Include: All Cloud Apps User Risk: high
Device Filter: Include All Devices,
Exclude isCompliant = True or
TrustType = Microsoft Entra hybrid Joined		 Block Sign-in frequency: Every time

Medium and high sign-in risk require MFA all cloud apps

Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: BreakGlass		 Include: All Cloud Apps Sign-in Risk: high, Medium Require Multifactor Sign-in Frequency: Every time

Review Workbook - Impact analysis of risk-based access policies

  • Impact summary of recommended risk-based access policies / High risk sign-ins not remediated using multifactor authentication - Shows the number of users not being prompted to MFA by a RBCA.
  • Impact details: Sign-in risk policy scenarios / High risk sign-ins not self-remediating using multifactor authentication by risk-based access policy - shows list of users that would have been impacted if RBCA was in place

Low, medium and high sign-in risk block register security information

  • Use when wanting to provide most protection to the tenant.
  • Should be set even with federated authentication to protect poorly managed in cloud accounts like shared mailboxes.
  • Goal is to prevent a user from being able to register security information with any kind of sign-in risk.
Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: Guest, BreakGlass		 User actions:
Register Security Information		 Sign-in Risk: low,
medium,
high		 Block Sign-in frequency: Every time

Low, medium and high sign-in risk block Microsoft management endpoints

  • Use when wanting to provide most protection to the tenant.
  • If any chance there is a sign-in risk when a users is trying to manage a component of Microsoft 365 or Azure they should be blocked.
  • Will need to work with a peer to clear the risk.
  • Here is the list of applications affected by this policy
Users Cloud Apps or Actions Conditions Grant Session
Include: All users
Exclude: BreakGlass		 Include: Microsoft Admin Portals,
Windows Azure Service Management API		 Sign-in Risk: low,
medium,
high		 Block Sign-in frequency: Every time

Low, medium and high sign-in risk block highly privileged role members

  • Use when wanting to provide most protection to the tenant.
  • Privileged Role Members = Directory Roles (Application Administrator,Authentication Administrator,Cloud Application Administrator,Conditional Access Administrator,Exchange Administrator,Global Administrator,Helpdesk Administrator,Hybrid Identity Administrator,Password Administrator,Privileged Authentication Administrator,Privileged Role Administrator,Security Administrator,SharePoint Administrator,User Administrator)
  • Include the directory sync account - Directory Role (Directory Sync Account) or create a separate conditional access policy
  • Will need to work with a peer to clear the risk.
Users Cloud Apps or Actions Conditions Grant Session
Include: Role - privileged roles
Exclude: BreakGlass		 Include: All Cloud Apps Sign-in Risk: low, medium, high Block Sign-in frequency: Every time

Low, medium and high user risk block highly privileged role members

  • Use when wanting to provide most protection to the tenant.
  • Privileged Role Members = Directory Roles (Application Administrator,Authentication Administrator,Cloud Application Administrator,Conditional Access Administrator,Exchange Administrator,Global Administrator,Helpdesk Administrator,Hybrid Identity Administrator,Password Administrator,Privileged Authentication Administrator,Privileged Role Administrator,Security Administrator,SharePoint Administrator,User Administrator)
  • Include the directory sync account - Directory Role (Directory Sync Account) or create a separate conditional access policy
  • Will need to work with a peer to clear the risk.
Users Cloud Apps or Actions Conditions Grant Session
Include: Role - privileged roles
Exclude: BreakGlass		 Include: All Cloud Apps User Risk: low, medium, high Block Sign-in frequency: Every time

Low, medium and high sign-in risk block Microsoft Intune Enrollment

  • Use when wanting to provide most protection to the tenant.
  • Goal is to prevent a user from being able to register a device with any kind of sign-in risk.
Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: Guest, BreakGlass		 Include: Microsoft Intune Enrollment Sign-in Risk: low,
medium,
high		 Block Sign-in frequency: Every time

High user risk block all cloud apps

  • Use when self service password reset and password write back is not enabled on Entra ID tenant.
  • Use when wanting to provide most protection to the tenant.
  • Requires for someone to research and respond to high users risk as they come in. (Usually Security Operations)
  • Allow on-premises password change to reset user risk will help with user risk clean up.
  • Recommended by CISA
Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: BreakGlass		 Include: All Cloud Apps User Risk: high Block Sign-in frequency: Every time

Review Workbook - Impact analysis of risk-based access policies

  • Impact summary of recommended risk-based access policies / High risk users not being blocked - Shows the number of users not being blocked by a RBCA.
  • Impact details: User risk scenarios / High risk users not being blocked by risk-based access policy - shows list of users that would have been impacted if a RBCA was in place

High sign-in risk block all cloud apps

  • Should be used when users are not registered for MFA while using cloud authentication.
  • Use when wanting to provide most protection to the tenant.
  • Recommended by CISA
Users Cloud Apps or Actions Conditions Grant Session
Include: All Users
Exclude: BreakGlass		 Include: All Cloud Apps Sign-in Risk: high Block Sign-in frequency: Every time

Review Workbook - Impact analysis of risk-based access policies

  • Impact summary of recommended risk-based access policies / High risk sign-ins not being blocked - Shows the number of users not being blocked by a RBCA.
  • Impact details: Sign-in risk policy scenarios / High risk sign-ins not being blocked by risk-based access policy - shows list of users that would have been impacted if RBCA was in place

References

⚠️ **GitHub.com Fallback** ⚠️