What is the simplest and quickest method to set up 2FA/MFA in 365 to ensure entire tenant compliance?
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, there are many methods that leave holes within the environment, so below, is our recommendations.
KEY POINT: Deliver 2FA/MFA to 100% of the entities within EntraID, (guest included) do not use groups to apply MFA, and ensure 100% of users/admins/service accounts/Guests/Externals etc, all have MFA enabled/enforced.
- Goto Security Defaults Information
- Goto Conditional Access Information
- Goto Common Errors in the Setup of MFA Enforcement via Conditional Access
- Goto BreakGlass Accounts
- Goto Service Accounts
SECURITY DEFAULTS
This is a quick, easy, and safe way to deploy the minimum requirements to your tenant. Microsoft is finally starting to enable MFA/2FA for all tenants where it is currently not ideally configured. It's far from perfect, but it's a great step in the right direction, and where you have no other methods of ensuring coverage, it's the best solution.
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 who do not have to remember to do anything else after, 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, 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
There is a common misconception that service accounts do not need to have MFA enabled, as they are required on servers where you cannot deliver an MFA response. Again, this is incorrect.
Suppose you have a server and have a service on that server that requires an MS365 account to operate. In that case, you can have that configured with MFA and then use "Named Locations" (which means known IP addresses) to not ask for MFA if a user (any user, but in this case, the server) is accessing from a particular "KNOWN" IP address. For example, this known address could be the data centre or an office location (REQUIRES MFA TO BE SETUP ON THAT ACCOUNT - NOT IDEAL).
Or, you can block access to log in on that account from any location except for the office/server location (BEST SOLUTION) - see below for two examples:
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. 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.
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 like 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.
The other option, for service accounts and rooms, etc, is to use the above, where we have "Any Location" set with Exclude "Selected Locations" as the offices/server locations etc, have these accounts specifically listed in the Users, and then the Grant (access control) to "Block access" - this will then use the IP address as the secondary factor, preventing the account logging in from anywhere else - thus not needing any MFA setup on the specific account itself. If using this option, you must exclude the service accounts from your "all users" policy.
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.