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, do not use groups to apply MFA, and ensure 100% of users/admins/service accounts 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
A quick, easy and safe way to deploy the minimum requirements to your tenant, and something Microsoft is now finally starting to enable, on all tenants, where MFA/2FA is currently not ideally configured. It's far from perfect, but is a great step in the right direction, and where you have no other methods of ensuring coverage, its the best solution.
Microsoft Article about Security Defaults in EntraID
Security Defaults is also ideal for companies with little or no ICT support and who want to deliver a good level of security to the environment, and 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.
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, although 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 where you are advised by Microsoft here, 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.
You can find these, if you have this issue, 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, where you can review, most likely identify they are 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 utilise Conditional Access, therefore, for many organisations, it is easier to utilise Security Defaults, rather than Conditional Access Policies, even, to be honest, if you have Entra ID P1 licenses.
Microsoft Article about Conditional Access in EntraID
Conditional Access, whilst making it more granular to control several aspects of security within Microsoft Office 365/Azure/EntraID, by nature, also instils some risk as this allows for humans to become involved in the security configuration.
You can access Conditional Access in several ways, but for us, we prefer using the Microsoft Azure Portal, where after logging in as an admin, you can search for and find Microsoft Entra Conditional Access.
Microsoft now provides templates for the deployment of the required Multi-Factor Authentication within your tenant, and if this is your first policy, you can just use their templates - select Policies from the Conditional Access Menu, where you will either see your live policies, or, nothing if this is your first policy.
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 that appear in the policy list.
We can now take a look at the policy in a bit more detail, and discuss the issues we commonly find 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 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 that it now works, then click on SAVE.
BREAK GLASS ACCOUNTS
There is a common misconception that a break-glass account should be configured not 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 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, however, 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. This known address could be the data centre, or an office location, for example.
Or, you can block access to log in on that account from any location except for the office/server location - 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.
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". For example, 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, if the account was compromised, it could not be used on another device within the, for example, 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 and log in from, but, not any account logging in from the data centre (or office); thus, we can enable MFA on our service account now, knowing it will not require MFA if it's our server in the data centre trying to authenticate.
This applies to conference room systems, door controllers, checking-in systems, scanners and printers, and even users in our office.
NOTE: We do not like excluding specific locations for users, this can lead to compromises where devices are left at those locations or servers at the location are compromised.
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 specifically blocked 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.