Breyta

Deila með

Block access for users with insider risk

  • Grein

Most users have a normal behavior that can be tracked, when they fall outside of this norm it could be risky to allow them to just sign in. You might want to block that user or ask them to review a specific terms of use policy. Microsoft Purview can provide an insider risk signal to Conditional Access to refine access control decisions. Insider risk management is part of Microsoft Purview. You must enable it before you can use the signal in Conditional Access.

Screenshot of an example Conditional Access policy using insider risk as a condition.

User exclusions

Conditional Access policies are powerful tools, we recommend excluding the following accounts from your policies:

  • Emergency access or break-glass accounts to prevent lockout due to policy misconfiguration. In the unlikely scenario all administrators are locked out, your emergency-access administrative account can be used to log in and take steps to recover access.
  • Service accounts and Service principals, such as the Microsoft Entra Connect Sync Account. Service accounts are non-interactive accounts that aren't tied to any particular user. They're normally used by back-end services allowing programmatic access to applications, but are also used to sign in to systems for administrative purposes. Calls made by service principals won't be blocked by Conditional Access policies scoped to users. Use Conditional Access for workload identities to define policies targeting service principals.
    • If your organization has these accounts in use in scripts or code, consider replacing them with managed identities.

Template deployment

Organizations can choose to deploy this policy using the steps outlined below or using the Conditional Access templates.

Block access with Conditional Access policy

Tip

Configure adaptive protection before you create the following policy.

  1. Sign in to the Microsoft Entra admin center as at least a Conditional Access Administrator.
  2. Browse to Protection > Conditional Access > Policies.
  3. Select New policy.
  4. Give your policy a name. We recommend that organizations create a meaningful standard for the names of their policies.
  5. Under Assignments, select Users or workload identities.
    1. Under Include, select All users.
    2. Under Exclude:
      1. Select Users and groups and choose your organization's emergency access or break-glass accounts.
      2. Select Guest or external users and choose the following:
        1. B2B direct connect users.
        2. Service provider users.
        3. Other external users.
  6. Under Target resources > Resources (formerly cloud apps) > Include, select All resources (formerly 'All cloud apps').
  7. Under Conditions > Insider risk, set Configure to Yes.
    1. Under Select the risk levels that must be assigned to enforce the policy.
      1. Select Elevated.
      2. Select Done.
  8. Under Access controls > Grant, select Block access, then select Select.
  9. Confirm your settings and set Enable policy to Report-only.
  10. Select Create to create to enable your policy.

After administrators confirm the settings using report-only mode, they can move the Enable policy toggle from Report-only to On.

Some administrators might create other Conditional Access policies that use other access controls, like terms of use on lower levels of insider risk.

Related content