Skip to content
English
Go to cybertecsecurity.com
  • There are no suggestions because the search field is empty.

Microsoft 365 Conditional Access MFA/2FA and Security Defaults

What is the simplest and quickest method to set up 2FA/MFA in 365 to ensure entire tenant compliance?

The compliant forms of MFA are:

  • FIDO2 credentials (on trusted platform devices or roaming keys)
  • Challenge-based authenticator apps
  • App-based code generators
  • Message-based methods (email, SMS, and call-based)

ONE OF THE ABOVE MUST BE USED TO BE COMPLIANT

Key point: There are absolutely no exceptions; You must utilise MFA on every sign-in-enabled entity in Microsoft 365, including DirSync, Email Relays, Teams Room systems, etc.

You may exclude MFA requests within trusted locations, but MFA must be in place and enforced for all sign-in-enabled entities in your tenant.

There are many "best practices" and "differing opinions" on how to set up and enforce Multi-Factor / Two-Factor (MFA/2FA) in Microsoft Office 365, and whilst many of these align with Cyber Essentials, many methods leave holes within the environment. Below are our recommendations.

Key point: Deliver 2FA/MFA/2SV to 100% of the entities within EntraID (guests and service accounts included), do not use groups to apply MFA, it's required for ALL USERS, so use the ALL USERS selection option.

 

SECURITY DEFAULTS

Security Defaults is a quick, easy, and safe way to deploy the minimum requirements to your tenant. Microsoft is finally enabling MFA/2FA/2SV for all tenants that are not currently configured for it. It's far from perfect, but it's a significant step in the right direction and the best solution when you have no other way to ensure coverage.

Microsoft Article about Security Defaults in EntraID

Security defaults are also ideal for companies with little or no ICT support who want to deliver a good level of security to the environment and do not need to remember to do anything else afterwards, as this ensures MFA/2FA is available.

My quick route to switch this on is by following this link: Azure Portal and then, after logging in as a 365 admin, accessing the Microsoft EntraID, which generally you will find nearer the bottom of the menu that appears when you select the hamburger menu button, top left in your browser window. (Within your MS365 admin portal you can access EntraID from the "Identity" menu)

Once EntraID appears, you can select "Properties" in the middle of the header in the centre of the screen.

At the bottom of the properties screen, in the middle, is a link allowing you to access the "Manage Security Defaults" settings. However, this doesn't necessarily look like a menu item.

You can then switch this on by enabling the option

If you are already using "Conditional Access" your screen will offer the "Manage Conditional Access" (like ours here) rather than "Manage Security Defaults."

There are some occasions when Microsoft advises that you are unable to enable security defaults because you have legacy conditional access policies—whenever we have seen this, they have never been in use, and we have merely had to delete them.

If you have this issue, you can find it by searching for "Conditional Access" in the search bar at the top of the screen and opening Microsoft Entra Conditional Access.

Select "Classic policies" from the Conditional Access Menu and ensure you are showing all policies. You can then review them, most likely identify them as old and not used and delete them. You will then be able to set up security defaults.

CONDITIONAL ACCESS

At the time of writing, Microsoft requires an Entra ID P1 license if you wish to use Conditional Access. Therefore, for many organisations, it is easier to use Security Defaults rather than Conditional Access Policies, even if you have Entra ID P1 licenses.

Microsoft Article about Conditional Access in EntraID

Conditional Access makes it more granular to control several aspects of security within Microsoft Office 365/Azure/EntraID. However, it also instils some risk as it allows humans to become involved in the security configuration.

You can access Conditional Access in several ways, but we prefer using the Microsoft Azure Portal. After logging in as an admin, you can search for and find Microsoft Entra Conditional Access.

Microsoft now provides templates for deploying the required Multi-Factor Authentication within your tenant. If this is your first policy, you can use their templates. Select Policies from the Conditional Access Menu, where you will either see your live policies or nothing.

Click on the "New policy from template", then select "Require Multi-factor Authentication for all users" and click on "Review + Create."

We would suggest you accept and "Create" the template as per the default, which is "Report Only" (until we are ready for go-live) and "Exclude Current User" (so if it goes wrong, you can still log in).

Once we have saved our first policy, we will see it appear in the policy list.

We can now examine the policy in more detail and discuss the issues we commonly encounter when reviewing Microsoft 365 Tenants for the enforcement of Multi-Factor Authentication.

COMMON CONDITIONAL ACCESS MISTAKES

As assessors, we like to ensure that Multi-Factor Authentication is set for the entire tenant user base (that is, any entity in EntraID, without exception). Therefore, the perfect Conditional Access Policy will be applied to "ALL USERS", "ALL CLOUD APPS", and, with the only exception, a single admin account (still having MFA enabled) to ensure that when you enable the policy if you have any errors, you don't lock out everyone.

This is "Perfect." What is never perfect is the application of MFA via a group, a group that requires someone to place users into the group, which means "a person is involved" and thus means "something that, regardless of process, will go wrong at some point."

Once we are happy, we need to set our policy to "ON" so it works, then click SAVE.

BREAK GLASS ACCOUNTS

There is a common misconception that a break-glass account should not be configured to utilise MFA/2FA/2SV, which is not the case. Break-glass accounts, in the Microsoft 365 sense, are those not assigned within Conditional Access or other similar policies, so they cannot be accidentally locked out, but they will have Multi-Factor Authentication enabled.

Microsoft Article referencing Break-Glass/Emergency Access Accounts

SERVICE ACCOUNTS

MICROSOFT STATMENT: “Some customers may use a user account in Microsoft Entra ID as a service account. It's recommended to migrate these user-based service accounts to secure cloud-based service accounts with workload identities.”

“If user identities are used to sign in as a service account to run automation (including scripts or other automated tasks), those user identities need to sign in with MFA once enforcement begins.” — Microsoft Learn documentation on mandatory MFA enforcement. 

Thus, we will still be looking to ensure that protection is in place on service accounts, which we will assess to confirm whether they are workload identities.

Whilst the NCSC no longer support using conditional access policies to use IP addresses as a method of MFA/2FA/2SV, Microsoft suggest that for Workload Identities, you should still add IP blocking to your workload identities for greater protection. See later for our method for IP blocking.

If you are using user-based accounts for service accounts, you should add MFA to those, and then add a location where it will not be asked for; thus, allowing the account to sign in and perform its task, without being prompted for MFA, but, should the credentials be stolen, MFA would be required.

NOTE: If you don't add MFA to the account here as well, when the credentials are stolen, the threat actor will be asked to setup their own MFA, defeating the entire point of having MFA.

Adding a location in Conditional Access for the location where the workload identity will sign in from, for example:

You select "Named locations" from the menu option on the left, within the Microsoft Entra Conditional Access section, and here you can set up "offices", "data centres", or indeed (a great feature) countries where you are allowed to log in from (that is another article).

Select "IP range location" from the menu.

Add your IP address(es) with a subnet mask reference (/32 = single IP, for example) and a name to make this easier to use later within the policies. We really suggest creating a group of IPs into a named location for ease, so if you have AWS Production, AWS Test, Office A and Office B, create those named locations separately.

Now, you can configure your Conditional Access Policy not to fire MFA requests when within that location.

Note: This method of "not" asking for MFA in a known location for things like service accounts, Teams Rooms, Mail Relays, etc, leaves a hole in security, as you still don't have MFA on the accounts, and therefore you need you to manually add MFA to them. We recommend having MFA set on the account, but also, using our IP blocking solution below to further protect the account.

Go back to your policy, edit it, and select "Conditions." You may also like this to not ask for MFA when a user is in the office, so you may want to use this globally.

NOTE: We think that users should have an MFA prompt wherever they are logging in from, thus ensuring that if the account was compromised, it could not be used on another device within the office location, where you would never know—for example, your SharePoint Data Store now accessible by the threat actor whilst on a server they have access to with the compromised user's credentials, never asking for MFA.

Here, we will select "Any Location" (as we require this policy to work everywhere) and then exclude only the data centre we set up earlier.

We now have a policy that will request MFA wherever our users (or any entity) try to log in, but not any account logging in from the data centre (or office); thus, we can enable MFA on our service account now (required with this solution), knowing it will not require MFA if it's our server in the data centre trying to authenticate (again not our preferred option).

This applies to conference room systems, door controllers, checking-in systems, scanners and printers, and even office users.

NOTE: We do not recommend excluding specific locations for users; this can lead to compromises where devices are left at those locations or servers are compromised, never asking for MS365 MFA. User Workload Identities instead of interactive-user-accounts.

The other option, for service accounts and rooms, etc, OUR PREFERRED OPTION, is to use the above, where we have "Any Location" set, with Exclude "Selected Locations" as the offices/server locations etc, but then in another policy, have these accounts listed explicitly in the Users, and then the Grant (access control) to "Block access" - this will then use the IP address as well as the manually added MFA, to further protect the account, preventing the account logging in from anywhere else. 

NOTE: We would recommend granular "per location" policies, as you would not have the copier from location A ever logging in from location B, so we would suggest that for the copier (Teams Room, Server, etc) at location A, they are blocked explicitly from login from anywhere other than location A with other location policies for servers or services at different places.

MAKE SURE YOU ALWAYS EXCLUDE 1 X ADMIN ACCOUNT FROM ANY CA POLICY IN CASE YOU GET IT WRONG (SAME ACCOUNT EXCLUDED ON ALL) AND ENSURE THAT THE ACCOUNT HAS MFA ENABLED.