In this guide we will be creating some further additional policies before fully enabling conditional access within our tenant. If you have not carryied out the required preparation from parts 1 and 2 then go back and read them to ensure you are ready and have carried out the required prerequisites.
In the previous guide we went through creating a basic “Require MFA for all Users” policy however in the real world you may not want this. There is some great work on conditional access policy examples by Daniel Chronlund, so I recommend you check out his work, and he even provides a downloadable spreadsheet which provides the configurations in an easy to read format.
For our test environment we have created separate simple policies for our standard user account (all users including guest accounts, but excluding administrative roles), and one for our administrative accounts, which require 2FA for all logins. The reason for this is so we can continue to show how to trouble shoot progressively more complex conditional access policies as we continue with these guides. If you are looking to roll out conditional access to a live environment while using these guides then refer to the above mentioned policy templates by Daniel Chronlund.
NOTE: As a reminder, the Microsoft list of prerequesites, and the full guide is available here. Also, our test environment is using Business Premium which includes Entra ID P1 (Azure AD P1), which means we do not have access to the user-based risk policies and conditions. To use the Entra ID user-risk policies with conditional access you will need Entra ID P2 (Azure AD P2).
Based on our report-only policies and using our log analytics workspace, we have been able to confirm over the assessment period that Legacy Authentication is not being used. Therefore we can use a conditional access policy to block it being used within our tenant.
NOTE: Microsoft has published some best practice guidance on naming conditional access policies which you can find here if it’s something you want to implement. You can find it here.
A quick reminder of where to find the Legacy Authentication report. Go to https://entra.microsoft.com select “Identity” > “Monitoring and Health” > “Workbooks” > then in the search bar type “conditional” and select “Conditional Access Gap Analysis” from the tiles as highlighted.
Once the workbook is loaded, select the time frame required, and then you will be able to view a breakdown of legacy vs modern authentication.
We recieve a message that we don’t have any users logging in to applications via legacy authentication within the selected timeframe.
The second message shows that we don’t have any application sign-ins using legacy authentication within the selected timeframe.
This means we can now create a conditional access policy which blocks legacy authentication. Again we will create a report-only policy and monitor it for a short while to be sure. To create the policy we stay in the entra portal at https://entra.microsoft.com select “Protection” > “Conditional Access” > “Create new policy from Template”.
Select the tile for “block legacy authentication”.
Then create the policy with the default values, using “Review + create” also leaving it as report-only. These can be adjusted if required for example, the only account in our test environment we want to exclude is our “break-the-glass” admin account (covered in the previous guide), and when using the templates the current user account is excluded to prevent accidental lockouts. We will go back into this policy and add our “break-the-glass” account and remove the account of the current user. We will also change the default name to match our own internal naming convention.
If you want to ensure all users (or just admins) are using strong MFA there is another setting we can use to ensure this. Previously we have a created conditional access policy which forces all users to use MFA when they login, but this would allow the use of SMS as the second factor which we do not want to permit, instead we want all users to use the Microsoft Authentictor app. The Microsoft explanation for the built-in authentication strengths and the level of protection they provide, including an easy reference table is here.
We can improve our current conditional access policies by changing the “Require Multifactor Authentication”, to “Require Authentication Strength”. This will then apply our configured Authentication Strength Policy, but first we need to create one.
This is easily done by going to https://entra.microsoft.com > “Protection” > “Authentication Methods” > then from the sub menu > “Policies”. Select “Microsoft Authenticator” from the method list.
NOTE: If we want our users to be able to use other authenticator apps such as Google Authenticator then we also need to create a policy for “Third-party software OATH tokens”.
We are targeting the All Users Group, and will allow both authenticator modes (Both push and paswordless). You can find the Microsoft explanation of the two types here. Although “Registration” is showing as “Optional”, we leave this as we will be setting a conditional access policy which will enforce registration.
We then configure the following settings as shown, allowing the use of OTP and require number matching for push notifications.
We want to show the application name, and show geographic locations in push and passwordless methods.
We leave the final setting using defaults.
We save the configuration and can now see that the Microsoft Authenticator policy targets the All Users Group. Also note that Email OTP is enabled, if you drill down into this setting you’ll see it only applies to Guest users and is enabled by default by Microsoft within all tenants since 2021. We can use a conditional access template to force MFA for all guest user accounts if required.
NOTE: If you already have accounts using weaker versions of MFA such as SMS then you may want to run a registration campaign to prompt users to upgrade their MFA method to the stronger Authenticator App method. The Microsoft guide for configuring a registration campaign is here.
Now we have our Authentication Strength Policy in place we now make changes to our conditional access policies. Still in our Entra portal go to “Protection” > “Conditional Access” > “Policies”.
Select the relevant policy. For us it is the two “Require multifactor authentication” policies.
Scroll down to “Grant”, and click the “1 control selected” link, to open the side menu options. Untick “Require Multifactor Authentication”, and tick “Require Authentication Strength”. Leave the dropdown menu at the default selection, and save our changes.
You should do this for the separate policies for all users and admin users.
Another thing to consider is whether we want to control how MFA methods are registered. Why would we want to do this?
User accounts can be compromised before the MFA registration process has been completed. This effectively bypasses MFA as the attacker is able to register the MFA method when first accessing the account (as if they were our new user registering for the first time) and get full access. However if we use a conditional access policy which restricts the way in which MFA can be registered then we can limit the likelihood of this type of attack impacting us. We can set policies which will require the MFA set up to occur from a trusted location (our office/s), or from an AAD registered, or Intune compliant device.
We can set these controls via a conditional access policy template in the same way as previously by going to our Entra ID portal at https://entra.microsoft.com > “Protection” > “Conditional Access” > “Policies” and selecting the relevant tile as shown below. Accept all the defaults, and then create the policy. Now select it from the list of policies so we can make some changes.
We want to include all users, but exclude all guest users, and our break the glass account. We need to exclude guest users as we will be requiring MFA registration to be intitated from an Intune enrolled and compliant device which our guests will not be using.
Just to touch on this quickly, yes this obviously means that guest accounts are a weakness as they lack the same controls as our full accounts, but this is where you need to be ensuring that guest accounts have the absolute minimum of access, and use other controls such as being set to auto expire after a period of time, to ensure the risk of these accounts does not spiral. In some organisations guest accounts are required and we need to ensure they are well configured, and the risk they introduce is minimised. They should still be configured to require MFA via guest specific conditional access policies.
The below screenshot shows where to configure a location configuration, however as we are a remote organisation we won’t be using this as we don’t want to force users to visit the office to register.
Let’s move on to “Conditions” > “Filter for Devices” where we configure our “Property” to “isCompliant” the “Operator” to “Equals” and the “Value” to “True”. This requires the device being used to be registered with Intune and be compliant. Make sure Configure is set to “Yes”. This means an attacker cannot register MFA unless they also have access to an enrolled and compliant device.
Now we select “Device Platforms” from the same menu set “Configure” to Yes, and include “Any Device”. Hit “Done” then save the changes to finish configuring the policy. It’s pointless if we lock down only Windows and MFA can be configured from a non-compliant iOS device, which is why we include all device platforms.
By now we should have everything in place to enable our conditional access policies. We have been monitoring our policies via the report-only setting and reducing the chances of encountering any issues when we fully enable them.
One thing we need to consider, if we have them enabled, is Microsoft Security Deafults. If these are enabled within your tenant then they will need to be disabled before conditional access can be fully enabled. This is however really easy to check from within any of our previously created conditional access policies.
From our Entra ID portal at https://entra.microsoft.com > “Protection” > “Conditional Access” > “Policies” > then select any of your policies from the list. Scroll to the bottom and if Security Defaults are enabled you’ll see a warning at the bottom as show below. Using the link opens the side pop out screen which will show if Security Defaults are enabled or disabled and give you the option to change the setting from within this screen.
Before disabling Security Defaults, be sure you understand the changes you are about to make within your environment as you could actually be reducing the security configuration of your tenant. The basic controls of Security Defaults include:
- Requiring all users to register for multifactor authentication
- Requiring administrators to use multifactor authentication
- Requiring users to use multifactor authentication when necessary
- Blocking legacy authentication protocols
- Protecting privileged activities like access to the Azure portal
We need to bear this in mind before disabling Security Defaults, as the intention is to improve our security posture not weaken it. Also have a final review of your conditional access workbooks to identify any possible issues.
If we’re happy, we go ahead and make the transition to conditional access.
From within the menu we select “Disable”, read the warnings and provide an answer to the Microsoft question if you wish, then save.
We can then go through and enable our conditional access policies one by one. It’s always worth double checking the exclusions of each as we go through them in turn to ensure that we have excluded our “break-the-glass” admin user account so we don’t lock ourselves out of our tenant. You may receive similar warnings as those shown below.
We are now using conditional access policies. Keep an eye on your Identity “Secure Score” to watch for any sudden drops, also visit your Entra recommendation portal regularly as it will often warn you if there is a configuration which is of concern. We can’t “set and forget” conditional access, they need to be constantly reviewed and evolved to esnure they continue to meet our requirements.
We will be continung with our Microsoft Security Guides and blogs in the coming weeks, so keep an eye out. Until next time.
@2codemonte 