This post is part of the overall MS-500 Exam Study Guide. Links to each topic as they are posted can be found here.

As we discussed previously, implementing appropriate security and controls around authentication to Microsoft 365 has never been more important. The very nature of a cloud service makes it open to potential attacks if considerations aren’t made to protect the environment. One of the easiest and most powerful controls we can put in place is adding Multi-Factor Authentication (MFA) to our user authentication flow.

MFA works by requiring an additional step of authentication from the end user during sign-in. There are a few different ways of implementing MFA which we will detail in this post. It’s important to be aware of the impact of legacy authentication on the different MFA methods so I recommend checking out my previous post on disabling legacy authentication:

PSA: The importance of disabling legacy authentication in Microsoft 365 – Sean McAvinue

Per-User MFA

Per-User MFA is a legacy configuration which is no longer recommended as it does not provide the flexibility or control that we require to provide a good user experience. Security Defaults or Conditional Access provide a better level of protection than per-user MFA so should meet any requirements. If Per-User MFA is still required, there are some things to note around configuring it.

Per-User MFA can be accessed via the Azure AD or Microsoft 365 admin portals via the Multi-Factor Authentication option in the All Users and Active Users sections respectively.

Some things to know about configuring Per-User MFA:

• There are there “User States” for per-user MFA:
  • Disabled – This is the default state and does not require MFA from the user
  • Enabled – The user is prompted to configure MFA at next sign-in. Legacy Authentication is not blocked at this point. When the user registers their MFA information, their status will transition to “Enforced”
  • Enforced – Users are required to provide MFA at each new sign-in attempt. Legacy Authentication is blocked apart from the use of App Passwords
• App Passwords can be configured to allow applications which do not support Modern Authentication / MFA to authenticate. App Passwords are complex passwords which the user can generate for single app usage. Generation of App Passwords can be disabled in the MFA service settings. As this is a global setting, I recommend disabling app passwords unless explicitly required in your organization

• Trusted IPs can be added to the MFA service settings, allowing bypassing of MFA from known locations. This is only available to configure for Azure AD Premium subscriptions. It is also not nearly as flexible as Conditional Access so not recommended. Trusted IPs can also be ADFS aware, requiring some configuration on ADFS, if a user authenticates via the Intranet zone in ADFS, we can also bypass MFA

• There are a variety of MFA options we can make available to our users, we can choose to disable some of the options:
  • Call to phone – The user will receive a call to the phone number they provide at registration, they can then confirm authentication by pressing a specific key during the call
  • Text message to phone – The user will receive an SMS message to the phone number they provided. This is not recommended for use in production due to risks associated with SMS
  • Notification through mobile app – Users can receive a push notification on the Authenticator app which they configure during registration
  • Verification code from mobile app or hardware token – The user enters a code which is displayed on the Authenticator app or Hardware token configured during registration.

• The option to allow users to remember MFA on devices they trust will allow the user to tick a checkbox at sign-in to allow their device to be approved for MFA for the time specified

Overall Per-User MFA is not an efficient method of enforcing MFA for users as it does not scale well. Security Defaults and Conditional Access are much more attractive options for large organizations.

Azure Active Directory Security Defaults

For organizations who want to secure their Cloud Services without having the in-house experience, need or time to define a tailored solution, Security Defaults is a very attractive option. Security Defaults is a single global setting that will take Microsoft issued, best practice, preconfigured policies and apply them to all users in the tenancy. Security defaults contains policies that implement some of the basic security policies we would expect from a production Microsoft 365 tenancy such as requiring MFA for users when required, block legacy authentication, enforce MFA for all admin accounts.

The exact configuration of these policies is not visible in the Azure Portal but has been documented very well here. Security Defaults can be enabled from the Azure AD Portal under “Properties” -> “Manage Security Defaults”

Security Defaults can only be enabled if you have no custom Conditional Access Policies enabled in your tenant. If you have custom policies, they will need to be disabled before Security Defaults can be activated.

Security Defaults is great for organizations who don’t have any specific needs other that to enhance their security posture, generally for larger organizations, flexibility around the configuration and application of security policies is required. In this case, all policies in the Security Defaults configuration (and lot’s more) can be deployed via Conditional Access rules.

Conditional Access

Conditional Access in Azure AD is a lot more than MFA. It is an extremely flexible and scalable solution to manage a wide variety of authentication use cases. At a high-level Conditional Access interprets “signals” which are essentially data we know about the specific authentication request, and applies a set of rules to the information gathered. Depending on the outcome of these rules, a decision is made about the authentication request, enforcing any requirements detailed.

To understand this better, let’s take an example. In our example, we want to enforce MFA for all users from Windows devices to all applications in Office 365 unless they are on an Intune compliant Windows device. We also want to bypass this requirement from our corporate LAN.

First, we need to make Azure AD aware of our corporate LAN so we can meet that requirements. We navigate to our Azure AD portal and open up “Security” -> “Named Locations”. We add a new location and give it a name, select IP Address and add in our corporate WAN breakout IP(s). Since this is our corporate office, we’ll also mark it as a trusted location to provide even more information to Azure AD. We don’t really need this for our policy but it will help any sign-in risk policies we configure later to assess the location as trusted.

When the named location is created, we can go ahead and create our policy. We open up the “Conditional Access” blade and create a new policy. We give the policy a name and start our configuration, I like to give Conditional Access Policies a prefix such as CA00x to help with documentation and reference later on. When creating a new policy, we have a lot of options available to us so let’s find the ones we want.

First we’ll apply our policy to all users by selecting “Users and Groups” -> “All users”. Note that we have multiple options here and can also exclude objects from our selection using the “Exclude” option. I do recommend having a “Break Glass” account excluded from all policies you create as a back door in the event of an MFA outage or similar platform issue.

Next, we want to specify that the policy will apply to all apps in the Office 365 suite. We select “Cloud Apps or Actions” and under “Select Apps” choose “Office 365”. We can also choose individual applications if we want and as before, can exclude a subset of apps from our policy.

Under “Conditions” we have two settings to configure, we select “Windows” in “Device Platforms” and under “Locations” we want to exclude our “Corporate LAN” range.

Finally, we add our grant controls. Under “Access Controls” -> “Grant” we select “Grant Access” and check the boxes for “Require multi-factor authentication” and “Require device to be marked as compliant”. As we only require one of these controls to be met, we choose the option to “Require one of the selected controls”. We have the option here to require multiple controls to be met simultaneously if we wanted to.

Before saving the policy, we decide if the policy should be enabled immediately or if we want to run it in report only mode. We will touch on report only mode in a later post but it is recommended to test all policies in report only mode before enabling for production. Configure this option and click create to save the policy.

Summary

We have looked at the different methods of implementing MFA for Microsoft 365. Conditional Access provides a lot more than just MFA and we will be using it a lot throughout the preparation for this exam. I really recommend testing different scenarios out in conditional access in a lab environment to get to know the different capabilities it brings to the table outside of MFA.

Here are some useful links for further reading around implementing MFA:

PSA: The importance of disabling legacy authentication in Microsoft 365 – Sean McAvinue

Enable per-user Multi-Factor Authentication – Azure Active Directory | Microsoft Docs

Azure Active Directory security defaults | Microsoft Docs

What is Conditional Access in Azure Active Directory? | Microsoft Docs