A bit of light reading today, but still an important topic worth discussing: Conditional Access! If you’re not very experienced with implementing these policies, this post might help set you up in the right direction.

Conditional access policies are powerful tools for hardening your security posture with, and are also among the first things I examine during my cloud security assessments. There’s a wide range of possible combinations with the various access and session controls available.  However, selecting the right or wrong combination of controls can set you up for a highly secure environment or a vulnerable one.

This post will not dive to deeply into the subject, but rather provide a high-level overview of some of my favorite conditional access policies to implement. I’ll talk about why the policies are important, give you tips on setting them up, and help you prepare for implementation.

Today’s post will cover the following sections:

• Policy 1: Require Multi-Factor Authentication
  • How to Configure
  • How to Prepare
• Policy 2: Block Legacy Authentication
  • How to Configure
  • How to Prepare
• Policy 3: Require Secure Access for Admins
  • How to Configure
  • How to Prepare
• Policy 4: Require MAM for Android & iOS
  • How to Configure
  • How to Prepare
• Policy 5: Require Session Policy for Unmanaged Devices
  • How to Configure
  • How to Prepare
• Wrap up

Policy 1: Require Multi-Factor Authentication

One of the most common, yet arguably the most important conditional access policy at your disposal is enforcing Multi-Factor Authentication (MFA) for both users and potentially guests. Keep in mind that even with MFA enforced, attackers can and will attempt to bypass it, using techniques such as man-in-the-middle and token theft attacks. However, this shouldn’t discourage you, because having MFA enforced is definitely far more secure than relying on passwords.

I won’t recommend for a one-size-fits-all approach to MFA policies because every organization’s has its unique needs. It’s essential for organizations to carefully consider the available options and choose the one (or multiple) that fits best with their situation. Ultimately, the goal is to ensure that users can sign in as securely as possible without flooding them with a barrage of MFA requests every time they are about to do anything. So balance is key here!

How to Configure

Many times, during discussions with the CTO or CISO at a company, they express the desire to, or may already be, requiring their users to reauthenticate with MFA every 14, 30, or even 90 days, and they prefer MFA prompts only when users are outside the office. However, most of the time, configuring the policy in such a manner isn’t truly necessary.

What’s important to understand is that users who sign in with Hello for Business (or FIDO2) on their Microsoft Entra ID joined device automatically receive a valid PRT token with an MFA claim. This means that users won’t encounter any new MFA prompts after their initial sign-in on their device. Yes, this is true!

So, if you have already widely implemented Hello for Business (or FIDO2) for your users, remember that there’s no significant drawback in simply requiring MFA consistently. If you’re in this scenario or can move towards it, you can confidently implement the policy outlined below.

In practice, there are many situations where this policy may not work optimal. For instance, when dealing with guests, external hires, users working from RDS, or essentially any user not working from a corporate device with with Hello for Business or FIDO2 enabled.

If you encounter such scenarios or something similar, you can create a separate policy and configure the sign-in frequency session control setting. This allows you to specify the duration before a user is asked to sign in again.

How to Prepare

Before implementing the “require multi-factor authentication” conditional access policy, there are a few things to prepare for:

Legacy MFA Migration: When using Conditional Access policies to enforce MFA, it’s important to transition away from the old per-user (legacy) MFA portal as quickly as possible, so say goodbye as it can potentially interfere with your policies. Microsoft has announced it will deprecate this way of enforcing MFA starting from September 30, 2024. You can start the migration from the authentication methods page in the protection section of the Microsoft Entra admin portal.

Authentication methods: After completing the legacy MFA migration, you can fully take advantage of authentication method policies. With these policies, you have full control over which authentication methods to allow, which ones to disallow, how they are used, and who can use them. Examples include disabling weak authentication methods for MFA like SMS or phone sign-in, enabling temporary access passwords for users who lost their MFA device, or even enforcing passwordless sign-in if you want to eliminate passwords entirely.

Keep me signed in button: By default, when users sign in, they have the option to click on the Keep me signed in button button, which stores a persistent cookie in the browser, allowing users to stay signed in even after closing the browser. I would highly advise disabling this button from the Entra ID user settings and instead work with the sign-in frequency setting in Conditional Access if necessary.

Policy 2: Block Legacy Authentication

Legacy (or basic) authentication protocols were the traditional way of authenticating using a username and password for a long time. Popular ones included SMTP, POP3, IMAP, and EWS. However, by today’s standards, they are definitely an insecure way of authentication, as they lack support for modern security features such as MFA, high encryption standards, and, for that matter, conditional access policies.

Because of this, we should all transition to modern authentication protocols quickly, such as OAuth, SAML, WS-Fed, and OpenID Connect. Microsoft has taken a proactive role in speeding up this transition by permanently disabling legacy authentication for Exchange Online starting from October 1, 2022. Sadly, I’ve noticed that many companies continue to rely on these legacy protocols. This is because Microsoft has not fully disabled it in all tenants yet and continues to allow SMTP authentication for the time being. Additionally, some companies have requested extended support for certain protocols.

How to Configure

So, let’s get rid of these legacy authentication protocols once and for all by disabling them, not only for the Exchange Online service but for all applications and services.

There are alternative ways to disable Legacy Authentication. For example, you can create authentication policies in Exchange Online or manually uncheck legacy protocols for users. However, using Conditional Access is the recommended method, as it enables you to block Legacy Authentication for all services and users at once.

How to Prepare

Before implementing the “block legacy authentication” conditional access policy, there are a few things to prepare for:

Identify usage: Always check if legacy authentication is still in use by users or service accounts in your environment. You can do this by navigating to the Microsoft Entra ID sign-in logs, adding the client app filter, and selecting all the legacy authentication protocols.

Transition to modern authentication: After identifying which accounts are still actively using legacy authentication, you should create a plan for transitioning these accounts to modern authentication protocols. Have discussions with your developers or software suppliers to make sure you can transition as soon as possible.

Policy 3: Require Secure Access for Admins

One of the worst scenarios for an organization is when an attacker gains access to one of your admin accounts. These accounts are prime targets because they provide attackers with the means to inflict significant damage on your organization. It’s important that we take the appropriate measures to protect these accounts, even if it means sacrificing some IT productivity.

If the organization can be persuaded to hand out FIDO2 for authentication, you’ll be able to eliminate the risk of phishing attacks, which are still the most common type of attack out there. If not, Microsoft Authenticator could be your second best option.

Additionally, if not already a standard practice for all users, requiring your admins to work from compliant devices can also improve your security posture significantly.

How to Configure

So, let’s create a policy to require secure authentication and working from a compliant device. Keep in mind that these controls aren’t the only combination available; you have the flexibility to mix and match, remove, or add any controls that better suit your specific scenario. For instance, you could also include session controls like:

• Sign-in frequency
• Non-persistent browser session
• Token protection for sign-in sessions

Furthermore, there’s a new app you can target called Microsoft Admin Portals, which is currently in preview. This could be an alternative to targeting directory roles.

If you’re aiming for an even higher level of security to protect your admin accounts, consider the option of building a Privileged Access Workstation (PAW) for your admins. There are multiple approaches to this, but Microsoft has described one of them here.

How to Prepare

Before implementing the “require secure access” conditional access policy, there are a few things to prepare for:

Authentication strengths: You’ll need to create a custom authentication strengths policy or choose from one of the pre-defined templates. After creating them, you can select them within your Conditional Access policy. Two of my personal favorites to include in the policy are FIDO2 as the primary method and Temporary Access Pass (TAP) as the backup method.

Authentication method registration: If you’re requiring a higher authentication strength, such as FIDO2, for admins, please ensure that admins can register for these methods first; otherwise, they may find themselves locked out of their accounts.

Separate admin accounts: You don’t want to target these policies at regular user accounts, so please create separate admin accounts for your administrators. This is way safer anyway, because these regular user accounts have access to services like email and Teams, which makes the account more vulnerable to phishing attacks. Also, make sure the admin account is created cloud-only and is not synchronized from on-premises AD, or else if compromised, suddenly your local AD might be compromised as well.

Separate Edge profile: Because you will be using a separate admin account, you will also need a separate device or alternatively use a separate Edge profile, which works just as well. If you don’t do this, Microsoft will not be able to check if you work from a compliant device and will block you from accessing the portal.

Policy 4: Require MAM for Android & iOS

Being able to access corporate data such as email, Teams messages, or office files from mobile phones is standard practice nowadays. But as we know, many of these devices are not corporately managed devices. According to research, 82% of companies allow the use of personal devices to access corporate data. This means we are up for a challenge in preventing data leaks and ensuring secure access from these devices.

Mobile Application Management (MAM) is an effective way to protect corporate data while respecting personal data on the device. It allows us to manage and enforce security policies that apply exclusively to corporate apps. Additionally, it enables us to selectively wipe corporate data when devices are stolen, lost, or when users leave the company.

The app protection policies that come with MAM can also be used for corporately owned mobile devices. However, in my experience, they are more crucial and commonly used when dealing with personal devices.

How to Configure

Configuring this conditional access policy is pretty straightforward. You will target the Android & iOS device platforms and require the app protection policy for users accessing corporate applications. See the full list of supported apps here.

Read this in-depth post if you need guidance on configuring MAM for Android and iOS.

Microsoft has also recently introduced MAM for Windows, but other platforms such as MacOS are not supported yet. There are not many capabilities for Windows yet, but if you are interested, I have recently written a blog about my experience with it during public preview.

How to Prepare

Before implementing the “Require MAM for Android & iOS” conditional access policy, there are a few things to prepare for:

App protection policy: To prevent users from being blocked from accessing corporate apps, always configure the app protection policy in Microsoft Intune, before setting up the conditional access policy. This will allow you to configure the security controls that will apply to the corporate apps, including:

• Data protection: Preventing actions such as copy/pasting, printing, screenshotting, or downloading of corporate data, and more.
• Access Requirements: Enforcing sign-in with a PIN or biometrics for accessing corporate data, and more.
• Device conditions: Blocking access for specific OS versions, manufacturers, or jailbroken devices, and more.

Broker app: After implementing both policies, users will need to install a broker app before gaining access to corporate applications. For iOS, this app is the MS Authenticator app, and for Android, it’s the Company Portal app. Ensure you communicate this change with your users beforehand, as they will be required to install the app on their personal devices.

Policy 5: Require Session Policy for Unmanaged Devices

Data leakage is becoming a concern for more and more companies, especially with information security standards and privacy regulations continuously getting stricter, and fines and penalties being handed out more often.

Data leakage can happen in many different ways, one of them is data leaking from cloud applications onto unmanaged devices. After data is saved onto the unmanaged device, it is essentially lost because we have no control over it anymore, unless you have some form of data encryption policy in place.

One course of action could be to just completely block these unmanaged devices in your environment, but a more balanced method is more suitable for most organizations. With this method, we are able to take control over the situation by putting certain restrictions onto the user to minimize the risk of data leakage.

How to Configure

We will configure the policy so that the use of a custom session policy is required whenever a user sign-in happens from an unmanaged device. We are only targeting Office 365 apps such as Microsoft Teams, SharePoint Online, Exchange Online, and OneDrive, but the integration of custom or third-party apps such as Google Drive, Salesforce, and Dropbox is possible.

If you want a more detailed explanation of how to configure this, check out another blogpost on this topic here.

How to Prepare

Before implementing the “Require Session Policy for Unmanaged Devices” conditional access policy, there are a few things to prepare for:

Session policies: You’ll need to create session policies within Microsoft Defender for Cloud Apps to define the restrictions you want to apply to users’ web sessions. Common restrictions include limiting download, print, or copy/paste actions for users using unmanaged devices.

Block access from desktop apps: I strongly recommend combining this policy with a separate one that blocks access from desktop apps for users on unmanaged devices. Otherwise, users will have access to desktop apps and data will still leak onto their devices. I’ll talk more about this additional policy in part 2 of this blogpost.

Licensing Requirements: Having a license for conditional access isn’t sufficient; you’ll also need access to Microsoft Defender for Cloud Apps, which requires an M365 E3 license. If you’re currently on a Business Premium license, you can use a similar conditional access setting called app-enforced restrictions, which I’ll talk more about in part 2 of this blogpost.

Wrap up

I’ve enjoyed sharing some of my favorite conditional access policies here and hopefully it helped some others in preparing for their own implementations. Stay tuned for more examples in a future post, so please come back to read it if you’ve found this post helpful.

My favorite Conditional Access policies to implement (part 1)