Conditional Access demystified, part 5: Implementing Conditional Access

Now available: May 2020 update of the Conditional Access Demystified Whitepaper, Workflow cheat sheet, Implementation workflow and Documentation spreadsheet

This article is part 5 of a series, for which the following articles are available:

Conditional Access demystified, part 1: Introduction
Conditional Access demystified, part 2: What is Conditional Access?
Conditional Access demystified, part 3: How does Conditional Access work?
Conditional Access demystified, part 4: Designing a Conditional Access strategy
Conditional Access demystified, part 6: Troubleshooting Conditional Access
Conditional Access demystified, part 7: Modifying Conditional Access to suit your special needs
Conditional Access demystified, part 8: Resources and further references

Before you start implementing your Conditional Access policies you should define an implementation strategy, some things to consider are:

  1. Make sure that Modern Authentication is enabled for Exchange Online (EXO) and Skype for Business Online (SfBO), SharePoint online has modern authentication enabled out of the box
  2. Create 2 break glass accounts, these accounts, which are global administrator should have complex passwords and will be excluded from any conditional access policy created and must have MFA disabled (or either one of two per account). More information about creating break glass accounts can be found here: Manage emergency access accounts in Azure AD – https://docs.microsoft.com/en-us/azure/active-directory/users-groups-roles/directory-emergency-access. Also keep in mind that you might want to change the default account settings for the Break Glass accounts using PowerShell: https://docs.microsoft.com/en-us/azure/security/azure-ad-secure-steps#step-2—reduce-your-attack-surface
  3. For each conditional access policy created, we will create an exclusion group, so that we can deal with exceptions in our environment. These exception groups will be setup with Access review functionality (if available) to make sure that the membership of these groups are evaluated on a regular basis.

Based on this we can define the following steps needed in order to implement your Conditional Access policies in the most ideal way.

Step 1: Check if modern authentication is enabled for Exchange Online and Skype for Business Online

Steps to check if modern authentication is enabled for Exchange Online and if not enable can be found here: Enable modern authentication in Exchange Online – https://docs.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/enable-or-disable-modern-authentication-in-exchange-online

Steps to check if modern authentication is enabled for Skype for Business Online and if not enable can be found here: Enable modern authentication for Skype for Business Online – https://www.ronnipedersen.com/2017/07/11/enable-modern-authentication-for-skype-for-business-online/

Step 2: Disable the legacy authentication protocols from the Office 365 accounts

Writing this down as a step is not really fair, since this can be a major change in your environment. Basically it start by monitoring how Exchange Online and Skype for Business Online are accessed, based on that determine the impact of this change. It might be that clients need to be updated to a newer version or that some special applications/services are accessing your environment using legacy protocols. The inventory should make this clear though and we have options to exclude certain accounts from our setup. In the end though it should be the goal to fully eliminate the use of legacy protocols.

Reference:  Protect Your Office 365 Accounts By Disabling Basic Authentication – https://www.adamfowlerit.com/2019/02/protect-your-office-365-accounts-by-disabling-basic-authentication/

Step 3: Enable the “Baseline policy: Block legacy authentication (Preview)” policy

Keep in mind that this policy is in preview, I do want to mention it though since it relates to Step 2. By enabling this policy and excluding the users which you identified in step 2 you make sure that legacy authentication cannot be used.

Step 4: If you don’t have them already, create 2 break glass accounts which will be excluded from any policy which could potentially block access to the Azure environment if something goes wrong

Step 5: If Microsoft leaked credential service is not enabled in your organization you should consider doing so. Microsoft is capable of validating if password hashes of your users are listed in leaked password services. If so, you can make sure that your users must change their password first before they can access the cloud app.

In this step you can also enable the following baseline policies:

  • Baseline policy: Require MFA for admins (Preview)
  • Baseline policy: Require MFA for Service Management (Preview)
  • Baseline policy: Block legacy authentication (Preview)
  • Baseline policy: End user protection (Preview)

At time of writing, all of the baseline policies had the label “Preview” which made me wonder if enabling these policies is supported in production environment. I reached out to Alex Simons, who is Corporate Vice President PM for Microsoft’s Identity Division, providing the following answer. “Yes, all public preview features in Azure AD are fully supported”

Also note that at time of writing the “Baseline policy: Require MFA for Service Management (Preview)” states to exclude at least one admin when enabling it, but provides no option to do so yet.

Make sure that you exclude the break glass accounts from these policies. Also note that Preview policies can have some issues, therefore you should enable them for a “preview” group in your organization first. Once the policies are out of preview you can enable them for the whole organization.

Step 6: Implement your own custom Conditional Access policies based on your Conditional Access design, make sure that for every policy that you exclude a specific group for that policy and also make sure that the break glass accounts are excluded as well. Make sure that you have a decent test plan to test the policies and modify your Conditional Access policies if needed in case something doesn’t work as expected.

Testing conditional access policies can be quite tricky. Main reason for this is that once a policy is enabled it’s not necessarily directly effective and it can take a while for it to become effective for your clients. This has to do with the fact that clients are not logging in all the time. Therefore, make sure that before you enable your Conditional Access policy that you know where you can find the logging (more on that in the next part of this series) in order to centrally determine if something is possibly wrong. Also make sure that all company procedures are followed for a change like this.

Step 7: Create a block all policy in order to make sure that you don’t miss anything and that holes in your conditional access strategy exist. The way this works is that you create the policy, but exclude all of the groups used (include and exclude groups) for the Conditional Access policies and of course exclude the break glass accounts. In this case we are sure that all users are covered by Conditional Access policy

Users not authorized within any of the Conditional Access groups will not be able to sign in from that point forward.

Azure has a safety feature that prevents you from creating a policy which violates the best practices for Conditional Access policies, so you can’t enable a policy for all cloud apps, for all users which denies access.

Policy Configuration not supported

The safety feature is necessary because block all users and all cloud apps has the potential to block your entire organization from signing on to your tenant. You must exclude at least one user to satisfy the minimal best practice requirement.

Some other things to consider are:

For all the exception groups make sure that you enable the “Access review” functionality (Premium 2 feature), for which you can find more information here:

Make sure that you have some operational procedures on what to do if certain functionality provided by Microsoft is down. A good example of this is the fact that in the past the Microsoft Multi Factor Authentication service has been down for a significant time. Having a operational procedure which allows you to make cloud apps available only from on premises when that happens without using MFA by disabling the “standard” policy and enabling a “temporary” policy might be a good idea.

Azure Active Directory Conditional Access changes on a regular basis, make sure that you have a procedure to check once in a while what is cooking on this topic. Make sure you understand what is coming, what is in preview and what is released. Invest time to determine the possible impact of these changes to the Conditional Access policies and requirements in place. You can see what’s new in Azure Active Directory here: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new and on the Azure Updates webpage here: https://azure.microsoft.com/en-in/updates/?product=active-directory&status=all&updatetype=features

Some cloud apps have dependencies with other cloud apps, for example Microsoft Teams has dependencies of Exchange Online, SharePoint and Planner and perhaps even more.

More information here: What are service dependencies in Azure Active Directory Conditional Access? – https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/service-dependencies I’ve created a flowchart which describe the steps described above, you can download this flowchart for your reference here: https://gallery.technet.microsoft.com/Conditional-Access-bbd04796

Conditional Access implementation flowchart

In the next part of the series (part 6) we will go into more detail on how to troubleshoot Conditional Access issues.