So Conditional access is one of the most fundamental and key products in any Microsoft cloud environment regarding security. Let's be honest, if you don't use it, you should implement it as soon as possible, together with MFA. It's one of the easiest way to achieve a high effectiveness in cybersecurity.

As a prerequisite, please understand the fundamentals of Conditional access.

Before we launch the policies, we first should ensure that all users have valid security information registered. (e.g. Microsoft Authenticator, personal phone number or e-mail address) Go to AzureAD, User settings and Manage user feature settings.

enable-the-combined-security-info
Source: Microsoft


Field examples

You may ask yourself, how do you configure it or whats the real use of it? Conditions vary and may often not show the desired result. In this post I want to present some best practice Conditional access policies from a technical perspective, that are effective and are easy to implement.

Block user security information from foreign locations

As I mentioned before, MFA and registered security information is the first step to take. But what if this was never done for a user? An attacker could easily register his own information, which is definitely not the goal.

Summarized: User security information can only be registered from a trusted location.

Implementation

  • Users and groups: all
  • Cloud apps or actions: User actions (dropdown) - register security information
  • Conditions: exclude your trusted/named location
  • Grant: Block access

All admins require MFA

Summarized: All privileged roles should always use MFA at each login.

Implementation

  • Users and groups: Directory roles - choose all
  • Cloud apps or actions: all cloud apps
  • Conditions: not configured
  • Grant: Grant access, require MFA

Block privileged role access from foreign locations

Simple attacks often are based from a foreign location. If all of these attempts are interrupted at the begin, you profit massively with almost no effort.

Summarized: Administrators can not login from foreign locations.

Implementation

  • Users and groups: all
  • Cloud apps or actions: all cloud apps
  • Conditions: exclude your trusted/named location
  • Grant: Block access

Block specific user groups

This one is a little more diverse. You need to understand your user groups and who has access to these accounts.

General users

General users are users that have no user affinity. That means they are used by multiple users, sometimes you don't even know who. It's very important to treat this accounts distinctive.

Summarized: Accounts that have on user affinity and hard to comprehend actions should be limited to trusted locations or IP addresses.

Implementation

  • Users and groups: general users group, (make use of AD attributes or groups)
  • Cloud apps or actions: all cloud apps
  • Conditions: exclude your trusted/named location (I would go with IP ranges that your users commonly work with)
  • Grant: Block access

Personal users

Personal user accounts are more easy to handle, with requiring MFA. You can also differentiate between a login attempt from a Hybrid Azure AD joined device or trusted location.

Summarized: Personal user accounts need to fulfill requirements at a login.

Implementation

  • Users and groups: personal user group (can be splitted into multiple groups)
  • Cloud apps or actions: all cloud apps (or specified)
  • Conditions: not configured
  • Grant: Grant access, require MFA, require Hybrid Azure AD joined device - require one of the selected controls

Require controls for specific cloud apps

Maybe you work with sensitive cloud apps, for example a VPN access. MFA, a compliant device, HAADJ, approved client app, app protection policy, or password change can be granted.

Summarized: Some cloud apps require special access controls.

Implementation

  • Users and groups: individual
  • Cloud apps or actions: specified cloud app (Enterprise application)
  • Conditions: not configured
  • Grant: Grant access, require MFA, require device to be marked as compliant, require Hybrid Azure AD joined device, require approved client app, require app protection policy, require password change

User- & sign-in risk policy

If Identity Protection (or other products like Cloud app security) trigger a medium or high risk for a sign-in or user, he will need to fulfill controls. I would recommend blocking the access when sign-in risk is medium and above and require MFA when user risk is medium and above.

Summarized: Risky sign-ins or users need to do actions.

Implementation

  • Users and groups: personal user group (can be splitted into multiple groups)
  • Cloud apps or actions: all cloud apps (or specified)
  • Conditions: User risk / sign-in risk, choose medium and high
  • Grant: Block access OR grant access, but require MFA or password change or any other control

Personally, I do not have any experiences with session controls, but keep in mind, that those offer even more granular control about interaction to online services. Read more about it

You’ve successfully subscribed to Oceanleaf
Welcome back! You’ve successfully signed in.
Great! You’ve successfully signed up.
Your link has expired
Success! Check your email for magic link to sign-in.