Multifactor Authentication identifies an end user with more than one factor. Authentication is based on something
you know, such as your password; something you have, such as a security token or smart card; or something that's a physical characteristic of who you are, such as biometrics. By creating an additional factor on top of the password, identity is better protected. Multifactor Authentication is seen as a must-have for cloud-based services, especially for administrative types of accounts.
At Microsoft Exchange Conference 2014, the company announced that Multifactor Authentication (MFA) would be available for Outlook 2013 this year and for Exchange on-premises in 2015. Office 365 MFA was made available for end users in February of 2014 without further license implications; it is not currently available for Small Business and Dedicated plans.
Configuring Office 365 MFA in your tenant is quite easy. In Users and Groups > Active Users, you can find the option to set up MFA. When end users are MFA-enabled, they need to complete the MFA setup process. This process is initiated when they access Office 365 using a browser, or they can be directed to a site to complete the MFA setup process (Figure 1).
End users can configure Office 365 MFA using their mobile or office phone numbers. These are known as "contact methods," which receive authorization codes through calls or, in the case of mobile devices, via text messages.
A more user-friendly option is the Mobile App. This uses an app on smartphones and is available on Windows Phone, iOS and Android. The app allows end users to confirm their identity (Figure 2). Another benefit is that it might prevent additional costs incurred as part of other contact methods, such as calling mobile or office numbers or sending text messages.
For end users to link a smartphone to their cloud identity in Windows Azure as part of the security verification process, they must enter a verification code in the app on their phone or scan a QR code from their screen using the app. End users must then use the app to confirm authentication, which is identical to confirming their identity in the log-on process when using the app. The ever-changing six-digit number should look familiar to those with RSA tokens, for example. The number can be used as a fallback mechanism when your phone is unable to connect to the Office 365 MFA service.
With a phone linked to your online identity, the authorization process requires end users to confirm their identity by clicking Verify in the smartphone app. They are then notified when the app is configured to receive push notifications. Alternatively, end users can check for pending authentication requests using "Check for auth" (Figure 3).
For applications that don't yet support MFA, end users can configure app passwords. This allows end users to bypass MFA authentication for certain applications such as Outlook or Lync or Exchange ActiveSync clients such as the Windows 8 Mail app. App passwords are nothing more than non-user configurable 16‑character strings that should be used as passwords when authenticating.
The general recommendation is to use the passwords per device so end users can easily invalidate passwords on a per-device basis should they lose the device. On the global level, organizations can disable app password use when security policies don't allow such a practice. Administrators can reset contact methods or app passwords for specific end users as well. Once MFA support is available for Outlook 2013, you should no longer be required to configure an app password for Outlook. Microsoft plans to add native MFA support to not only Outlook, but also to Lync, Office applications and OneDrive for Business.
This concludes part one of configuring Multifactor Authentication in Office 365. In part two, we'll look at how we can use the Azure Active Directory Module for Windows PowerShell to configure Office 365 MFA.
About the author
Michel de Rooij is a consultant and Exchange MVP from the Netherlands. Michel started originally as a developer back in 1994 but quickly switched to infrastructure-related projects and started focusing on Exchange in 2004, covering a number of areas, including migrations, transitions, consolidation and disentanglement. Besides Exchange, Michel's other areas of interest are PowerShell, Active Directory, Lync and messaging in general. Michel is a contributor to The UC Architects podcast theucarchitects.com and blogs about Exchange and related subjects at eightwone.com.