In today's "always connected" environment, allowing users to access applications from anywhere is a standard mandate. Depending on the application itself, the first step is often finding a cloud-hosted version of the application. In this article, we'll focus on email, of which there is no shortage of cloud offerings. We'll narrow down further on Office 365 which is currently the second most popular option and has steadily eroded Google's market share lead over the last two years. We'll look specifically at how to lock down your Office 365 instance to ensure all users and devices must perform Two-Factor Authentication (2FA). After all, the benefits of global accessibility to your email shouldn't also apply to fraudsters!
Microsoft has voluminous documentation on their built-in support for 2FA using Azure AD Premium, so we'll break ranks and instead look at how to do this using 3rd party identity federation/authentication products.
In some respects, email was one of the very first cloud applications in the internet age. Due to that length of time, there is no shortage of email clients and protocols that relate to sending and receiving email messages. The protocols started with POP3 then IMAP for reading and SMTP for sending. HTTP-based sites were born with added to the ubiquity of browser-based email access. Over the years, Microsoft added their own proprietary mechanisms such Exchange ActiveSync for mobile device connectivity, MAPI and Exchange Web Services (EWS).
Below is a more detailed look at the most common clients and protocols specific to Office 365 email and how they can support 2FA. These all assume you have already federated your Office 365 domain with an Identity Provider (IdP). The IdP could be Microsoft ADFS or a 3rd party product like PortalGuard or Ping Identity.
Microsoft Outlook Client
The full Outlook 2013 and 2016 clients support Microsoft's "Modern Authentication" which honors identity federation settings at the domain level and allows an IdP to fully control the login process. With Modern Authentication, first-time users in Outlook see a browser popup during account setup that displays your IdP's login screen and any 2FA requirements it enforces. The 2FA login is enforced through this window initially, but the Outlook client then caches this authentication for up to 90 days to prevent annoying popups. Here are a few pertinent notes:
- Modern Authentication is enabled by default in Outlook 2016, but you'll need to change the registry to enable it for Outlook 2013.
- If Kerberos is enabled on the IdP, users will NOT see this browser popup since they're receiving SSO to the IdP itself. In this case, you must either require 2FA at the desktop login or configure the IdP to perform step-up authentication for Office 365.
Microsoft Outlook Mobile App
Outlook Web App
This is the standard browser-based interface to Office 365's email and calendaring. It should come as no surprise that 2FA via identity federation works like a charm since the use of HTTP is front and center.
Native Mobile Email
This is where things get interesting. The built-in mail functionality on mobile devices typically use different protocols (e.g. POP3, IMAP, SMTP, EWS, ActiveSync) that do NOT support Modern Authentication. In these authentication protocols, there is no way to interact with the end user to prompt them for 2FA or allow them to enter an OTP. As such, there is generally no way for an IdP to seamlessly require 2FA for these legacy protocols. It may be possible for the IdP to utilize a true "out of band" second factor like a "push" to their mobile device that they accept or reject, but this is generally not cost effective for an entire organization. Furthermore, informing end-users of any errors is simply not possible due to the lack of a user interface.
Disabling support for these protocols for or specific users or the entire environment is the primary way of closing these security holes. There are at least two caveats to this approach:
- It may impact other Office365 services or any on-premises Exchange/hybrid environment you may have. Please consult Microsoft's documentation and work with Office 365 support for further details and to determine potential impact. Here are some specific resources for each protocol/entry-point:
- Prepare for the inevitable Help Desk calls from users who have already configured email on their phones through this method. Before disabling these protocols, be sure to communicate acceptable alternatives to your user population and the date when the protocols/support will be disabled.
Hope this clarifies the benefits of Two-Factor Authentication and provides some avenues for you in your quest to better control access to your Office 365 environment. Please let us know if you'd like further information about how PortalGuard can secure your email and other web applications in a user-friendly and cost-effective manner.
Additional Resource: Interested in learning more about Mobile Authentication? Download the free white paper, The Argument for a Better Authenticator!