Multi-Factor Authentication and Office 365 - Better protection, better security

A reading of an old (well, 2012) but still pertinent Wired.com article titled “Kill the Password: A String of Characters Won’t Protect You” caused me to revisit my password habits. Don’t get me wrong. I like to be secure and I have long employed complex passwords changed frequently to protect my data, but the information contained in the article was chilling because it revealed how attackers can easily compromise accounts that are password protected.

Insofar as possible, my accounts are now protected with Multi-Factor Authentication (MFA), which then brings me to the question of why Office 365 tenants remain happy to use just passwords. I can’t say how many or what percentage of Office 365 tenants use MFA, but a casual and not-very-scientific survey among my contacts reveal that MFA usage is not the norm, possibly because of a fear that the demand for extra authentication will irritate and confuse users. I have not found this to be the case in practice, but I certainly understand how people might feel that way. However, now that both Office 2013 (the latest version) and Office 2016 support OAuth-based authentication (sometimes called “Modern Authentication”), perhaps now is a good time for tenant administrators to consider whether MFA can help secure user data.

Introducing Office 365 MFA

First, let’s define what MFA is. It is a method of authentication that requires the person seeking access to data to be able to verify their identity in at least two ways. In most cases, it’s two out of these three methods:

The idea is to present attackers with multiple layers that they have to penetrate to be able to gain access to an account. Where guessing a password was sufficient, the attacker has to have the device used to respond to authentication challenges (like a phone) or be able to defeat a biometric challenge, something that is dreadfully hard to do.

The secondary authentication methods supported by Azure Active Directory is varied and includes phone call, text message, mobile app notification , verification code, and third party OATH tokens (that’s not a typo – a difference exists between the OAuth standard and OATH tokens). More information about Azure Active Directory MFA is available on their web site.

Azure Active Directory is the authentication authority for Office 365. Applications developed to support MFA use the Active Directory Authentication Library (ADAL) to authenticate to services using OAuth 2.0. OAuth is an open standard for authorization that is supported by many other vendors. Client applications, like Outlook or Outlook Web App, use ADAL to gain access to user data using access tokens acquired through the authentication process. Using access tokens mean that the applications can continue to access data without having to store or provide user credentials.

In fact, two types of tokens are used. A refresh token is issued following a successful user authentication. This is the master token that is used to acquire the access tokens necessary to access user data. For example, when an Outlook client first connects to and authenticates with Office 365, a refresh token is obtained from Azure Active Directory. Outlook can then use the refresh token to get an access token that’s valid for Exchange. The same refresh token is valid across Office 365, so if Word or Excel needs to access information in SharePoint or OneDrive for Business, the client-side applications can request an access token that is valid for those server applications. Another way of thinking about it is that an access token is always specific to a resource, be it Exchange, SharePoint, or something else.

If it is not used, a refresh token lasts two weeks. However, if the refresh token is used to generate access tokens, it is refreshed by Azure Active Directory. Of course, if you go away for more than two weeks and don’t access Office 365 during that time, the refresh token will expire and will need to be reestablished through authentication.

Enabling MFA for Office 365 accounts

Enabling MFA for Office 365 accounts is straightforward. Login to the Office 365 Admin Center, go to Users, then click the “Setup” link beside “Set multi-factor authentication requirements”. You can now bulk-enable MFA for multiple accounts or select individual accounts to be enabled. Click Enable to start the process and then confirm the accounts for which MFA is to be enforced.

The next time the now-enabled accounts are logged into, the user will be asked to complete the MFA enablement process by providing the second authentication method. As you can see in Figure 1, I’ve opted for a text message to be sent to a mobile phone. A six-digit code is sent by SMS to the designated phone and the recipient has to input that number into the browser to complete the process.

Figure 1: Selecting verification methods for MFA

Azure Active Directory has now connected the designated mobile phone with the account. When additional authentication is needed for an account, Azure Active Directory sends a verification code to the phone and the user can input the code in response to the challenge. This method works well for browser applications and for modern mobile applications that use ADAL, such as the Office 365 Groups app. Phones can also be used for authentication by receiving a call. In this case, the user acknowledges the call by answering it and pressing # on the keypad to complete the process.

Alternate authentication

Azure Active Directory supports the ability to enable multiple authentication methods for accounts to accommodate situations such as when users mislay their smartphones. Of course, no one realizes that they need an alternate method until a problem arises, but it’s a worthwhile exercise to determine whether these methods should be used in your organization.

Sometimes phone calls or text messages are not an appropriate authentication mechanism. For example, if you use a WiFi connection on an airplane, you won’t be able to receive a phone call or text message to complete the authentication process. But if WiFi is available, you can use the Azure Authenticator app (available for iOS, Android, and Windows Phone) to receive push notifications. The app can also be used offline to generate codes that can be used for authentication.  Of course, if you don’t have the Authenticator app and a network connection is unavailable, you will be restricted to whatever offline access is supported by your client.

Before you can use the authenticator app, your Office 365 account has to enable it as a verification mechanism. To do this, go to Office 365 Settings, Additional security verification, and click update your phone numbers used for account security. You can then add the Azure Authenticator app to the options supported for the account and complete the configuration process (Figure 2).

Figure 2: Configuring the authenticator app

App passwords

Not all applications support the verification methods listed above, which is the reason why the “app password” mechanism exists. An app password, which is issued in the final stage of MFA enablement (see Figure 3), is a complex text string that can be input to complete the authentication process. App passwords were created to allow applications that don’t support OAuth-based authentication to create a valid access token to gain access to Office 365 data.

Figure 3: Viewing an app password

Once issued, the user has to keep the app password safe because it will be required to authenticate by some applications including ActiveSync-enabled mobile phones. This part of the process is the most painful because even though you can have multiple app passwords (for instance, one per app or one per device), they’re all automatically generated and are guaranteed to be impossible to recall when you need them. In any case, this page explains how app passwords work and how to manage them.

MFA doesn’t become apparent immediately it is enabled as users might have existing connections that need to expire be logged out before the new authentication regime becomes effective. The usual thing is for browser connections to require MFA first (including connections to SharePoint and OneDrive when opening files stored in these repositories), then other apps like Outlook 2016. Once authentication has occurred, it is valid for 14 days.

Using MFA

It takes a little time to become used to MFA, but after a while it is second nature. You are not prompted for credentials more often than before, but when you are, it is a two-step process. Receiving a text message with the verification code (Figure 4) works well in most cases. The only problem I’ve had is when I’ve been working outside of my home country when a slight delay can occur as the telecommunications companies figure out how to get the SMS message containing the verification code to my mobile. The joys of roaming! In this case, the Azure Authenticator app might be a more convenient option. 

Figure 4: Entering a one-time code received via SMS

PowerShell MFA

The biggest issue I ran into is the lack of support within PowerShell for MFA. When you start up a remote PowerShell session to connect to Office 365, you can only provide a username and password as no mechanism exists to pass a second authentication factor, including app passwords. The only solution is to use a different account for PowerShell work. In itself this isn’t a big deal and it is good practice to separate administrative work (like what you would do with PowerShell) from day-to-day interaction with Office 365. Microsoft is in the process of adding MFA support for PowerShell and you will be able to use the different verification methods in the future. Note that the PowerShell modules for different applications, including Exchange, might not support MFA in the first instance. And even if they do, you should still consider using a separate account for PowerShell work.

PowerShell can be used to review the accounts that are configured for MFA. As explained in this article by MVP Michel de Rooij, you can run the code shown below to report the Office 365 accounts that use MFA and the methods used for secondary authentication. The data below indicates that both accounts are configured to use SMS authentication (OneWaySMS) and calls to a mobile phone (TwoWayVoiceMobile). You can also use PowerShell to manipulate the MFA settings for accounts, but most will be happy to use the Office 365 Admin Center as it’s a lot easier and less prone to error.

Get-MsOlUser | Where {$_.StrongAuthenticationRequirements} | Select UserPrincipalName, @{n="MFA"; e={$_.StrongAuthenticationRequirements.State}}, @{n="Methods"; e={($_.StrongAuthenticationMethods).MethodType}}UserPrincipalName              MFA      Methods            -----------------              ---      -------            [email protected]   Enforced {OneWaySMS, TwoWayVoiceMobile}[email protected]     Enforced {OneWaySMS, TwoWayVoiceMobile}

The case of the unhappy browser

A more curious problem was when Internet Explorer suddenly started to refuse to connect with MFA (Figure 5). I run the latest version of Windows 10 (10586, or the Threshold 2 build) and both Edge and Chrome were perfectly happy to use MFA where IE was not. I did all the normal things like clearing the browser cache and some research online for error code 50012, but couldn't turn up a good answer. The situation persisted for a week or more before I concluded that I should disable MFA for my account to see whether IE would respond. IE worked after MFA was disabled and continued working after MFA was re-enabled, thus proving once again that switching something off and on again is often a good way to fix a problem.

Figure 5: An error with IE

Remember that if you disable MFA and then re-enable it for an account, the user will be forced to go through the process of setting up verification methods again. 

A question of planning

Obviously, MFA is not something that you should implement on a whim, unless you want to have the help desk collapse under a barrage of calls from frantic users who want to access their mailboxes. Some up-front preparation and especially some up-front communication with users is necessary to ensure that everyone knows what’s going on and how to respond when prompted for additional verification. It’s also wise to verify that applications work smoothly with MFA and to build an FAQ (perhaps based on Microsoft’s FAQ on the topic) that can be shared with users to tell them what to expect during the authentication process.

Although Microsoft has made MFA generally available for Office 365, this functionality isn’t limited to the cloud service. You can configure Azure Active Directory MFA to service on-premises mailboxes too. MVP Brian Reid covers the topic on his blog and additional information on using MFA with on-premises applications and planning for hybrid deployments is available from Microsoft.

And of course, if you don’t use Office 365 but are interested in securing Exchange with MFA there are plenty of third party solutions available, as a simple web search will prove. Speaking of third-party solutions, if you use service accounts to grant access to your organization for a monitoring or other solution, it’s usually not a good idea to implement MFA for these accounts unless you know that the third-party solution supports this configuration. Some solutions already support MFA, some support app passwords (one good reason why is that the ISV doesn’t want to store passwords on behalf of tenants), and some simply don’t support MFA at all.

MFA capabilities are found in more applications over time and will become the norm. For instance, Microsoft recently added MFA to Rights Management protection for a number of clients, including Office 2016 applications. This is a nice feature that underlines the sensitivity of information to recipients who are forced to identify themselves with MFA before they can open a protected file.

Overall, Microsoft has created an easy-to-use implementation of MFA within Office 365 and is rolling out applications that take advantage of MFA. Flexibility exists in that tenants do not have to use MFA and if enabled, its use can be restricted to specific accounts. If you don’t use MFA today, maybe now is the time to test it with a few accounts. After all, what can you lose from better protection?

Follow Tony @12Knocksinna