Azure Multi-Factor Authentication (MFA) enables businesses to increase security for user authentication by enabling an additional challenge layer to simple usernames and passwords. There are three types of authentication challenges:
- Something You Know = username and password
- Something You Have = physical authentication device
- Something You Are = biometrics
Username and password combinations are almost always required as this provides the identity that is trying to authenticate. MFA is the requirement to satisfy more than just this combination by requiring either the “something you have” or “something you are” challenges.
Azure MFA Types
It can be confusing when speaking about Azure MFA as there are several ways it can be consumed. The key is that regardless of how you consume Azure MFA, it is all the same service underneath.
- MFA for Global Admins: With Azure and any Office 365 subscription, a reduced set of Azure MFA features are available to enhance security for these privileged accounts. This is at no additional charge or license requirement, but is only available to Global Administrator accounts.
- Consumption Model: Azure MFA can be subscribed to as an individual service based on consumption. Consumption is either per-user (unlimited authentications) or per-authentication.
- Suite Feature: Azure MFA is included in Azure AD Premium for unlimited authentications per licensed user. Azure AD Premium can be subscribed to as a stand-alone service, but is also included in the Enterprise Mobility Suite and Enterprise Cloud Suite.
In general, Azure MFA uses either a mobile device or a dedicated phone line to perform the secondary authentication. These verification options are configurable as part of the underlying Azure MFA service, but enabling more than one option allows the users to choose which verification option they prefer to use.
- Call to Phone: This places a phone call to the defined phone number in the user’s profile, requiring the user to respond with a specific key-press. The greeting and the response key-press are able to be customized.
- Text Message to Phone: This sends a One-Time-Passcode (OTP) via SMS messaging to a mobile phone. No response is necessary on the phone as the client prompts for the OTP to be entered.
- Notification Through Mobile App: This uses the mobile Authenticator app available on iOS, Android and Windows Phone mobile devices. A push notification is sent to the device requiring the user to either accept or deny the authentication request on the device itself.
- Verification Code From Mobile App: The same Authenticator app mentioned above also generates a rolling OTP. No response is done on the mobile device as the client prompts for the OTP to be entered.
There are two deployment approaches to enabling Azure MFA for Office 365 and Azure services: Azure MFA Service Deployment and Conditional Access Deployment. The Conditional Access (CA) approach is a more recent development for Azure MFA, and can be confusing in how to configure.
Configuration of the Azure MFA service is quite simple and well documented by Microsoft, so I am not going to repeat their instructions here. Despite being simple to enable, and Azure MFA deployment does require proper planning to ensure a positive user experience and acceptance of being required to use MFA.
Azure MFA Service Deployment
When Azure MFA was still relatively new, this was the only option for deployment. The downside is that it is an all or nothing approach to enabling Azure MFA. When enabled, all access to Office 365 and Azure services required MFA, but not all clients could process MFA challenges.
To oversimplify, Azure MFA was designed to work with browser based applications that could leverage the Azure Active Directory Authentication Library (ADAL), otherwise known as Modern Authentication (Modern Auth for short). This was a challenge for non-browser based applications, such as Outlook and Exchange ActiveSync (EAS) that are used religiously by almost everyone.
To address this, Microsoft included the concept of App Passwords into the Azure MFA service. An App Password is a 16 lower-case alpha-character password that can be entered into clients that do not support Modern Auth.
This feature has had a poor acceptance and adoption among Office 365 customers for one main reason… it circumvents all MFA requirements. Instead of entering the user account password in a client, the App Password could be entered which allowed the client to bypass MFA challenges. This allowed clients not capable of Modern Auth to be used, but it also allowed users to bypass MFA in any client as the App Password could be used for any connection.
These passwords are long, but have lower complexity requirements than standard Active Directory policy in that they only consist of lower-case letters. This makes them much easier to exploit than complex passwords.
This deployment option is good for smaller deployments where all clients are capable of Modern Auth so that App Passwords can be disabled. This is unlikely in any large or complex business, which leads into the use of Conditional Access.
Conditional Access Deployment
Conditional Access (CA) is not only for Azure MFA, but an identity protection feature within Azure for all services. Azure MFA can be leveraged by CA to enable MFA challenges under specific scenarios. CA can evaluate several conditions present when a user performs an authentication, such as group membership, device compliance, and specific cloud application trying to be accessed.
The most common scenario is that MFA should only be required when users are authenticating from locations outside the company network. With the Azure Service deployment, this is not possible as the Azure Service deployment is an all or nothing approach.
In addition, the challenge with native EAS mail apps can be addressed by excluding MFA for EAS connections. Your initial thought may be that this isn’t a solution any better than App Passwords as it circumvents MFA requirements, but with CA you can also enforce device compliance and registration so that only trusted devices can access EAS, which is not possible with App Passwords alone. The other thought here is that if the same device connecting via EAS is the device that will be used for to complete the MFA challenge, it seems pointless to require MFA on that device. Hopefully device compliance policies are also enforced that require device security, such as a complex passcode to unlock the device to be used at all.
Conditional Access Configuration
Like almost everything else with Microsoft, CA configuration for MFA is not as simple as there are still two Azure portals (Classic Portal and Resource Manager portal), and of course they operate independently of each other.
CA policies are cumulative, meaning that if multiple policies apply to a specific user, all conditions are logically AND’ed resulting in all conditions across all policies must be met. This applies whether there are multiple CA policies in the Classic Portal, Resource Manager portal, or across both portals.
The Resource Manager portal (which is referred to as the new portal from here on) will eventually replace the Classic Portal. Therefore, I include the configuration for the Classic Portal in this post, but if you are deploying Azure MFA for the first time, you should be using the new Azure portal.
If you have enabled users for MFA in the past using the Azure MFA service, this part can be confusing. For CA to work properly, you must disable Azure MFA for the users.
This may appear to be counter productive, but if the user status is Enabled (or Enforced) they must adhere to the Azure MFA Service deployment in which ALL authentication attempts use MFA. Despite the user being Disabled in the Azure MFA user settings, as long as they have the proper licenses applied, they can still leverage the Azure MFA service for two-factor authentication.
Configuring Azure MFA with CA is very flexible, so there is no one size fits all approach. Therefore, my example configurations are to meet the specific requirements of:
- MFA should be required for external (off-network) connections only
- EAS for native mail apps should always be excluded from MFA
- Intune is not deployed and no other MDM solution is being used
- ActiveSync Policies in Exchange Online are used and must still be enforced
My demo environment consists of:
- Cloud manged accounts (no directory synchronization or ADFS in use)
- Office 365 E3 and Enterprise Mobility Suite licensing
Azure Classic Portal Configuration
CA is not clearly represented in the Classic Portal as it is not listed as a configuration option. Instead, CA is configured on each individual application within each individual Azure directory instance. Going to my directory under Azure AD and opening the Applications tab, I can see that Office 365 Exchange Online is an available application.
Opening the properties of the Office 365 Exchange Online application shows the rules available to enable CA, despite they aren’t labeled specifically as such. The first set of settings applies to MFA.
The first few settings are basic scope of where the policy will apply, but the last setting for Rules needs a little more attention. The three options are self-explanatory, as this is how we can define to require MFA only when clients are outside the company network, but first I need to define my company network for this to work.
The link for Click here to define/edit your work network locations will open up the Azure MFA service configuration portal. This portal will include a list of Trusted IPs in which you can enter in your network’s outbound public IP addresses in CIDR format. These IP addresses are those where outbound network traffic leaves the company. If a company should own a block of IP addresses, chances are the network routing is configured for outbound traffic over a subset of that IP range. This list should include all outbound public IPs, so remote office locations should also be considered and included when necessary.
So far this has only enabled MFA for outside connections. The second part of the Office 365 Exchange Online app configuration contains device rules which also need to be enabled to exclude EAS connections from requiring MFA regardless of if they are on the internal WiFi or outside the company.
This is where the configuration becomes tricky for my requirements. The device settings here are being presented in the Azure Classic Portal, but they actually belong to the Intune Conditional Access Policy for Exchange Online. Intune Conditional Access requires device enrollment and compliance, but my requirements do not want to require Intune device enrollment. Therefore, I have to look at my CA policy to apply to non-compliant devices.
In Intune a policy must apply to compliant devices. Because I want to exclude only EAS, which should be used on mobile phones only, I have the option of Only selected devices must be compliant, other devices will be allowed access selected with the sub-option of Windows devices. This results in all iOS, Android and Windows Phone devices from being excluded and allowed access through the policy. Windows devices would consists of full Windows OS, meaning desktops and laptops.
To scope which applications the policy will apply to, I am selecting For only native applications. This includes native mail apps using EAS, but excludes browser based applications that may be used. Therefore, Safari on iOS and Chrome on Android would still receive the MFA challenge even though they are on the same mobile device that EAS is excluded from.
Finally, I make sure that device compliance for Exchange ActiveSync is not enabled. This is what is actually allowing the EAS connections to connect regardless of Intune compliance.
As mentioned earlier, these configurations are actually in Intune, which are shown below. Updating the Azure portal will automatically update the policy in Intune as well as vice versa.
If you have worked with Intune in the past you probably already know that any changes in Intune are not instant. In fact, in executing my testing for this example configuration I had delays of 24 hours until configuration changes were actually applied. If, for some reason, you are using the Classic Portal to configure CA for MFA, make sure you provide sufficient delay time in your testing to accommodate the slow application of configuration changes.
Azure Resource Manager Configuration
As mentioned previously, policies defined in the Classic Portal, Intune and the new portal are cumulative, so make sure you are aware of any existing policies across these other management interfaces that could impede or conflict with configuring CA for MFA in the new Azure portal.
Conditional Access policies are configured against an Azure Active Directory instance. In the new portal, I can access my CA policy by opening the Azure Active Directory blade for my specific directory instance and then selecting Conditional Access to display the Conditional Access blade.
This blade has a tab for Policies and Named Locations that I had to define to meet my specific MFA requirements. To make sure MFA challenges are only required for connections from outside my company’s network, I had to define a Named Location object that contains all my outbound IP addresses.
Note that I only have one Named Location defined, but if I had multiple offices with their own outbound Internet connectivity, I could define Named Location objects for each office. The benefit to this would be I could apply policies based on specific offices rather than simply internal vs external.
One thing that is very decieving here is that there is a link for Configure trusted IPs listed on the Named Locations blade. Clicking this link will take me to the Azure MFA service settings for Trusted IPs. This seems like it would make sense, but CA policies in the new Azure portal reference Named Locations, not the Azure MFA service Trusted IPs list for policy evaluation. Therefore, configuring Trusted IPs in the Azure MFA service itself will not impact my CA policy evaluation, and would result in undesirable functionality should I define Named Locations in the new Azure portal.
Clicking on my Main Office object, I can see the IP address ranges associated to my office’s outbound Internet connections.
Note that these are IP ranges entered in CIDR format. Since I have individual IPs, I simply have defined the subnet mask as 32 bits to represent a single IP address versus a range.
Now that I have my company’s network defined as a Named Location, I can leverage that location in a policy so that my MFA challenges are required for only external connections.
Going back to the Conditional Access main configuration blade, I can create or view my policies under the Policies tab. Here, I have already created a policy named External MFA Required.
Opening the policy configuration blade has initial settings that define the scope of the policy, such as users or groups to apply the policy to as well as what cloud apps and services the policy applies to.
Being able to define the cloud apps that the policy applies to is a significant benefit from using the Classic Portal, which required policies to be defined on each cloud application or service individually. Here, the new Azure portal allows my CA policy to apply to any combination of cloud apps and services I have in my subscriptions.
Opening the Cloud Apps tab, the configuration blade shows two tabs to define apps and services to include in the scope of the policy and any that should be explicitly excluded. Here, I have selected All Cloud Apps as this applies my policy to everything in my tenant and subscriptions. I have used this versus selecting individual services as it will automatically include and apply to any new services that are added to Office 365 or that I subscribe to within Azure. I can use the Exclude tab to explicitly define any apps or services I do not want my policy to apply to.
This defines the scope of where my policy applies, but not the conditions that have to be met for authentication to be allowed. Going back to the main policy configuration blade, opening the Conditions blade presents several options to configure.
The first pertains to device platforms where we can specify Android, iOS, Windows Phone and Windows (desktop OS) platforms specifically. Because my policy should apply to all devices, I leave this not configured as this doesn’t evaluate platform as part of the policy.
The second option for Locations is something I do want configured as this is where I can apply my policy only to connections outside the company network. Here I do configure this condition and apply it to All Locations under the Include tab. Similar to how the Cloud Apps scope worked above, I first want to include everything as it is the broadest scope possible, then use the ability to exclude specific locations.
Looking at the Exclude tab, I am given the option to exclude All Trusted IPs. The wording here is misleading as Trusted IPs are a configuration within the Azure MFA service itself. Even clicking the link for Configure all trusted locations will take you to the Azure MFA service Trusted IPs page.
The policy evaluates the Named Locations, not the Trusted IPs in the Azure MFA service configuration.
The last condition that must be defined is the Client Apps. Here, I have configured the policy to apply to Browser and Mobile apps and desktop clients. This essentially says apply the policy to everything. Even though there is a configuration option shown here for EAS, I do not have this configured as this only requires EAS clients to be on a supported platform. Using the new Azure portal for CA, EAS is not included for MFA requirements by default.
Now that I have a scope and conditions defined for my policy, I need to define the actions under the Access Controls section on my policy’s main configuration blade. Here I grant access while selecting the sub-option of Require multi-factor authentication.
By enabling this policy, I now am requiring all external connections outside my company network to complete an MFA challenge when authenticating unless it is using EAS.
As mentioned before, it would be a good practice to ensure EAS policies are enabled in Exchange Online to ensure device partnerships are monitored and controlled so that unknown or malicious users cannot use mobile devices and EAS to access cloud services.
As a user, before I can start using Office 365 applications that have been protected by Azure MFA, I first need to complete my MFA settings for my account. This can be done in two ways. First, I can try to access an application that is protected by MFA from a client that is Modern Auth capable (browser, Outlook 2016, or even the Outlook mobile app). Alternatively, I can go directly to the MFA setup website at https://aka.ms/MFASetup.
If I take the first option, after entering my username and password, I would be informed that I cannot log in until additional security verification have been setup. Clicking the Set it up now button takes me to the MFA setup website.
Going to the MFA setup site gives me the option to select what method I want to use for MFA challenges. I have the option to use a mobile phone number, which I can receive a verification call at or an SMS text messsage with an One Time Passcode (OTP). Alternatively, I can select my office phone number to recieve a verification call. This option is less desirable as it requires me to be at my desk to receive the call, and in my example scenario above would not be the case where MFA would be required. The last option, which I prefer, is to use the mobile app.
The mobile app give me two options. I can receive a push notification through the app which I can tap a response to accept or deny the authentication request or I can use a verification code (OTP) that is displayed in the app itself. One benefit to using the verification code is that the app uses a rolling OTP that is available offline, so if my mobile device does not have cellular or WiFi connectivity, I am still able to complete my MFA challenge. Before I can move forward and setup my app, I need to install it on my device.
The Microsoft Authenticator app is available from the Google Play Store for Android devices or the Apple App Store for iOS devices. Downloading and installing the app is done just like any other app on a mobile device, so no additional explanation should be necessary here.
After the app is installed on my device, I can go back to the MFA setup page and click the Set up button to configure my app by adding my account to it. This is where it is beneficial to setup my MFA settings from a browser or desktop app client instead of a mobile client.
Setup of the app can be automated using the QR code displayed on the setup screen. When adding a new account, I selected to add a Work Account as this is to be used with Office 365 (not to be confused with a Personal account that can be used for public Outlook.com accounts).
The app will need access to the camera on the device to scan the code, but doing so will automatically configure my app to link to my Azure AD account. Should I be using my mobile device to setup MFA (using the Outlook mobile app or Safari on iOS or Chrome on Android) I wont be able to scan the QR code being displayed on my device’s screen. Luckily, there is an alternative method to manually setup the account by entering the URL and the unique code presented on the setup page. I have redacted this detail from the screenshot.
Now when I go to log into my Office 365 applications and I enter my username and password, I am challenged for my MFA verification. Here, I am being prompted to enter in the OTP that is displayed in my mobile app.
Should I not be able to access my mobile app, I always have the option to click the link for Use a different verification option which will allow me to receive a verification phone call or an SMS text message with an OTP. If my mobile device’s phone number was not defined for my account either being administratively entered in Azure AD or synchronized from my on-premises Active Directory account, the MFA setup will prompt me to to enter my mobile phone number as a backup verification method.
But if I do have access to my mobile app, I can simply type in the OTP code that is displayed in the app to complete my MFA challenge verification.