MFA in Office 365 – Notes from the Trenches.

In this tutorial, I wanted to try something a bit different. Instead of just doing a simple how-to guide on setting up Multi-factor Authentication in office 365. I wanted to cover some of my experiences and notes in actually implementing MFA on customers tenants.

Microsoft bosts that MFA prevents 99.9% of account compromise. However, this statement is true to an extent. However, you don’t have to google too much to find an abundance of different MFA bypass methods that have started to circulate the internet. This will only get worse once more security researchers direct their focus towards it.

That said, ” I do believe MFA is a good start to secure any office 365 tenant”. Mix it with Conditional Access and Risk-based access and you will be able to prevent pretty much all but the most sophisticated of attacks.

There are 3 different ways to implement MFA in office 365, these are Security Defaults, Per User MFA and Conditional Access. Below I cover each method on how to implement MFA, For example, the user experience and any benefits or drawbacks.

Firstly, the table below Is a quick overview of the benefits and drawbacks of each different implementation of Multi-factor Authentication. It’s worth just taking a moment to take this in before moving on to the next section.

Policy	Security Defaults	Per User	Conditional Access
Standard Set of Security Rules to Keep your company safe	*
One-click on/off	*
Included in office 365 Licensing	*	*
Pre-configured templates in Microsoft 365 Admin Center wizard	*		*
Configuration flexibility			*
Exempt users from a policy		*	*
Authenticate by phone call or SMS		*	*
Authenticate by Microsoft Authenticator and Software tokens	*	*	*
Authenticate by FIDO2 Windows Hello for Business and hardware tokens		*	*
Blocks Legacy Authentication protocols	*	*	*
New employees are automatically protected	*		*
Dynamic MFA triggers based on risk events			*
Authentication and authorization policies			*
configurable based on location and device state			*
Support for “report only” mode			*
Ability to completely block users/services			*

Security Defaults

As the name suggests, All new tenants come with Security Defaults enabled by default. This is a set of preconfigured security settings that includes requiring all users to register for Multi-Factor Authentication.

However, this also blocks Legacy Authentication and protects Privileged actions. Microsoft Basically say if you are using the Free Tier of Azure Active Directory Security Defaults is for you.

One neat feature of Security Defaults, is users get 14 days grace to setup MFA on there account. A feature you can only usually get with Azure Active Directory P 2 license.

The problem is that there is no configuration at all, Security defaults options are either enabled or disabled and there will come a time when you have to disable this to enable or allow specific settings. Obviously, as this is a tenant wide setting any changes affect everyone.

Check Security Defaults

Check Security Default settings in Azure Active Directory, Click Properties and then click Mange Security Defaults found at the bottom of the page.

Then you should get the option to enable or disable security defaults.

One thing to consider when Deploying MFA via security defaults is you are only able to use Multi-Factor Authentication using only the Microsoft Authenticator App using notifications. For other authentication methods, you will have to use per user MFA or conditional access, both covered later in this tutorial

The table below shows the Different Authentication methods available in Security Defaults compared to Conditional Access and Per User MFA.

Method	Security Defaults	Conditional Access / Per User MFA
Notification Through Mobile App	x	x
Verification code from mobile app or hardware Token	x	x
Text Message to Phone		x
Call to Phone		x
App Passwords		x

Per-User MFA

Per-user MFA allows you to turn on MFA for any specific user on the tenant. However, like with security Defaults, Once enabled Multi-Factor Authentication happens every time that specific user signs in. There is no real configuration for this it’s just on and on for everything. There are some exceptions you can add, such as when a user signs in from a trusted IP address or you enable the trusted device feature.

One bonus of using Per-User MFA is that you can use Call and Text (SMS) for authentication over Security Defaults use of just the authenticator app.

Microsoft actually would prefer you to use Security Defaults or Conditional Access, over Per-user MFA as these are tenant wide settings. Per-User MFA has to be enabled individually on each user which leaves room for a busy administrator or support desk to miss enabling it when creating new users..

Before getting into rolling out Per-user MFA, take a look at the table below it covers the 3 states you can set on each user’s account. These basically reflect whether an admin has enrolled the user in Per-User MFA or not.

State	Description	Legacy Authentication	Browser Apps Affected	Moden Authentication Affected
Disabled	The default state for a user not enrolled in per-user Azure AD Multi-Factor Authentication.	No	No	No
Enabled	The user is enrolled in per-user Azure AD Multi-Factor Authentication, but can still use their password for legacy authentication. If the user hasn’t yet registered MFA authentication methods, they receive a prompt to register the next time they sign in using modern authentication (such as via a web browser).	No. Legacy authentication continues to work until the registration process is completed.	Yes. After the session expires, Azure AD Multi-Factor Authentication registration is required.	Yes. After the access token expires, Azure AD Multi-Factor Authentication registration is required.
Enforced	The user is enrolled per-user in Azure AD Multi-Factor Authentication. If the user hasn’t yet registered authentication methods, they receive a prompt to register the next time they sign in using modern authentication (such as via a web browser). Users who complete registration while in the Enabled state are automatically moved to the Enforced state.	Yes. Apps require app passwords.	Yes. Azure AD Multi-Factor Authentication is required at sign-in.	Yes. Azure AD Multi-Factor Authentication is required at sign-in.

All users start out Disabled then when you enrol users in Per user MFA their state changes to Enabled. when enabled users sign in and complete the registration process their state changes to Enforced. You are able to move between states, including from enforced to enabled or disabled.

Set up Per-User MFA

There are two ways to access Per-user MFA. The first is from the Microsoft 365 admin center Click users, then Active users and you should see a button that says Multi-Factor Authentication along the top of the window.

The Second way to access Per-User MFA is via Azure Active Directory, Click users and you should see a button for Per-user MFA at the top.

Both buttons take you to the same Multi-factor Authentication Page, shown below. When you access this page for the first time the status of each account will be set as disabled. The users may also show as disabled if MFA has been set up with Conditional Access. However, there’s more on Conditional Access later

To Enable per-user MFA, find the user you want to enable MFA for and check the box next to their name. A menu will show on the right-hand side under quick steps, Select Enable.

After enabling Per-User MFA, As a result the next time the user signs in they will need to register their authentication methods. With the authentication methods set the status will automatically change to enforced.

Don’t manually change the user’s MFA state to enforced unless the user has already registered their authentication methods. This will lock out the user from registering their details and block them from getting into their account.

There is not a lot you can change in Per-User MFA however what a lot of people dont realise is that there is a Service Settings tab, highlighted below. This gives you a few Global options like allowing users to create App Passwords or setting trusted IPs. You can even choose the verification options to use.

MFA Via Conditional Access

Conditional Access allows you to automate the whole process of rolling out MFA. As a result, taking away the pain of setting users individually and giving you more granular options to make the whole process run smoothly… “You don’t want MFA on the MDs iPhone?? This is not a problem with conditional Access”.

The one caveat of Conditional Access is that you need to have at least one Azure AD Premium P1 Liscance for each user on your tenant to gain access to the Conditional access blade. This can be either purchasing an Azure AD Premium P1 liscance on its own or a license that includes Azure AD P1 like Microsoft 365 Business Premium or Microsoft 365 E3/E5.

Make sure to disable Security Defaults or Per-User MFA before creating a conditional access policy as these settings take precedence over any thing set by Conditional Access.

Create a Conditional Access Policy

To Create a Conditional Access policy start by navigating to the Azure Active Directory Portal, browse to Azure Active Directory > Security > Conditional Access. Then select New Policy.

The New Conditional Access policy window will appear. There are many different ways we can configure conditional access policies in your tenant. However, in this tutorial, I am going to only cover setting up MFA for all users in a tenant. For example of other policies check out the Common Conditional Access Policies over on Microsoft Docs.

Start creating a conditional access policy by giving it a descriptive name, then move to the users and groups section. From here you can select who this policy will apply to. There is also an option to exclude accounts from this policy which is handy to add to any break-glass accounts you might have.

I would advise you to add a single user to the policy first so you can test the user experience before you go balls deep and add all users on the tenant to the policy.

Move to the cloud apps or actions section. From here you can now choose which apps this policy is going to apply to. I am going to select all cloud apps as I want MFA applied everywhere however you can include or exclude whatever apps you want.

Next, it’s time to set the conditions in the policy. This allows you to fine-tune what actually will trigger the MFA prompt for this example I’m just going to set Any Location now to make everyone register for MFA. However, later I will come back to this policy and exclude any trusted locations from it because if you are physically onsite and connected to the office Wifi you probably don’t need to get an MFA prompt.

We are not going to set any more conditions in this MFA policy but it is worth Checking out the other conditions that are available. You can subsequently specify which devices the policy affects or maybe even you need a setting like don’t prompt for MFA if the device is hybrid Azure AD joined or the device has to be marked as compliant. You can even use these conditions to specify the Authentication methods aloud on the tenant and restrict them appropriately.

Moving down the policy to Access Controls and Grant, As a result, you need to select Grant access and tick require Multi-Factor Authentication. Click Select to confirm the settings at the bottom of the Grant Blade.

There are other conditions you can specify in this Grant blade that are worth having a play with but are outside of the scope of this MFA tutorial.

Lastly, in the policy, there are the sessions controls. You can probably just leave this blank unless you want to set sign-in frequency or choose if you want to allow persistent Browser Sessions. For this policy, I am going to choose sign-in frequency for instance to 180 Days and leave everything else as is.

Slide the enable policy to On and Click Create to complete the policy.

Conditional access policies can take up to 4 hours to apply although usually, it happens within the hour.

Check Modern Authentication

Modern Authentication enables features like Multi-Factor Authentication (MFA) smart cards and other third-party SAML providers to work in your office 365 Tennant. As a result Modern authentication is based on the Active Directory Authentication Library (ADAL) and OAuth 2.0.

All Office 365 tenants created before August 1 2017 will have modern authentication enabled by default however I have come across this recently quite a bit where Moden authentication has not been enabled yet due to the customer being an original adopter of office 365. If Modern Authentication is disabled you will find when you go to enable MFA Outlook will just not connect and continue to ask for a password which you end up having to setup an App Password for the user.

Enable Modern Authentication

To enable Modern Authentication, log into the Microsoft 365 admin Center and select, Settings > Org Settings > Select Modern Authentication in the services tab.

In the Modern authentication blade, tick the box next to turn on modern authentication for outlook 2013 for windows and later (recommended). This is also the same spot where you can disable basic authentication however we will cover this more later.

To Check Modern Authentication in Powershell run the command below when connected to the office 365 tenant. As a Result this will output True if Modern Authentication is enabled…

Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled

Or False when Modern Authentication is not enabled. However, You can easily Enable Modern authentication by just running this command below.

 Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

Modern Authentication in Outlook 2013

If your organization for some reason is still rocking Outlook 2013, Then you need to enable Modern Authentication manually in outlook for these users. Otherwise, Outlook 2013 continues to use the legacy authentication by default and you will find the users having issues connecting to their email once MFA is enabled.

Before doing anything make sure the outlook 2013 client is fully updated… Then to enable Modern Authentication in outlook 2013 you need to set the registry keys below on each Client. Obviously this change could be rolled out to everyone via Group Policy if needed.

Change EnableADAL to 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL

Change Version to 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version

With these Registry keys set in Outlook 2013, it will try to use modern authentication first but can still fall back to legacy authentication if modern authentication fails and the email server still accepts Legacy authentication. To prevent this you can set the registry key below

Change alwaysUSeMSOAuthForAutoDiscover to 1 
HKEY_CURRENT_USER\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover

In Outlook 2016 Modern Authentication is enabled by default. However, Microsoft recommends to change the registry key “AlwaysUseMSOAuthForAutoDiscover” to 1 to force Outlook to always use Modern Authentication.

Disabling legacy Authentication

With all your users connected using MFA and modern authentication, You are probably now in a position to start disabling any legacy authentication on the tenant. However, if security Defaults is enabled Legacy authentication is disabled by default.

To start even considering disabling legacy authentication on your tenant you need to ensure that clients won’t be affected or prevented from signing in to their accounts. You do this by reviewing the Sign-in logs in Azure Active Directory, The trick here is to Use the filtering to display all users still logging on with Legacy Authentication.

To access the sign-in logs go to Azure Active Directory and scroll down to Monitoring and select sign-in logs.

Add the client App Column to the sign in logs, as this displays the applications accessing the Office 365 tenant.

You can then filter on client app and just tick the box against legacy Authentication clients to filter on them.

Play with the filters a little you can actually glean quite a lot of information form these logs, Once you are confident nothing is using Legacy authentication, you can safley disable legacy authentication by opening up the Admin portal and going to settings > org Settings > Modern Authentication.

In the Modern Authentication blade, You then have the options to disable all the different types of legacy authentication within your tenant.

MFA + Self Service Password Reset (Combined Registration)

Before combined Registration, users registered there authentication methods for Azure AD Multi-Factor Authentication and the Self-Service Password Reset (SSPR) separately. This meant that you essentially have to enter the same information multiple times and this confused a lot of users.

All new tenants Starting August 15th 2020 will have combined registration already enabled.

Below, shows the two prompts the users receives when combined Registration is disabled. First, you get the Initial MFA prompt…

then once you complete the process you have to verify your phone number again.

As you can see this is not ideal and confused a lot of users. So as the name alludes to “combined registration”, combines both these into one single registration experience for the user.

Enable Combined Registration

To Enable combined Registration Sign in to Azure Active Directory, click Users then user settings. then at the bottom of the page click manage user feature settings.

Unless you are setting this up for some sort of test group, change users can use the combined Security information registration experience to All.

Once combined Registration is enabled your users will receive a totally different prompt and will only be asked to add their details Just the once.

App Passwords

App Passwords are an alternative to multi-factor authentication for applications that do not natively support modern authentication. Typically I have to use this when a user demands that they want to use the inbuilt email client on their phone instead of the outlook app

App passwords are autogenerated and should be created and entered only once per app. There is a limit of 40 passwords per user. If you try to create one after that limit you will be prompted to delete an existing password before being allowed to create the new one.

App Passwords do not work with conditional access enabled you have to enable, per-user MFA to get the App password option to be available to the user.

Create an App Password

To Set a App Password for a user, log in to the office 365 tenant as the user. Once logged in select the user icon in the top right-hand corner of the screen, Then select View account.

On the my account page, select update info in the security info box as pictured below.

You will then be presented with the security info page, You should see all the different authentication methods set up for that user. To Create a new App Password select Add method.

In the Dropdown Select, App Password, Click Add.

If the app password option is not available make sure you have set the user up in per-user MFA on there account and enforced it.

Add a Descriptive name for the password, Click Next.

You Should now be presented with an app password. copy this password and use it in place of your regular office 365 password on any device, MFA and modern authentication do not work on. When finished click Done.

Once back to the main security info page the new App password is present. But you will be unable to see what the actual password is again. If you lose these details you have to recreate a new App Password.

Remove app passwords at any time by clicking Delete to the right of the password. As a result devices using that deleted app password will no longer be able to connect to the tenant.

Conclusion

Hopefully this has helped a few People out there, However let me know If it has or hasn’t or if you have any questions about any of this leave me a comment below, i read them all..