Many organizations have stated policies for requiring multi-factor authentication (a.k.a. “2-step verification”) when accessing sensitive data from outside the corporate network. When moving to the cloud, you are moving the data outside of your corporate perimeter, and you are also allowing your user to access it outside the same perimeter – both the data and the user lives outside your firewalls. This changes the rules of the game, and the existing service access policy must often be updated to reflect these new parameters.
If not considering the big picture, what cloud and SaaS actually means, and by not considering modern security measures such as Conditional Access or Rights Management Services for protecting content instead of just limiting access, it is easy to implement a too complex solution that lead to low user adoption and basically no usage in the mobile context (which Office 365 is very much about). The added complexity of an “MFA everywhere mindset” can actually give an opposite effect – people finding their own ways to solve the problem through rogue IT solutions based on commercial cloud services. A good rule of thumb when designing the service access solution is that “it should never take more time to get connected to do the work than it takes to actually do the work”.
This article presents considerations to take when meeting multi-factor authentication (MFA) requirements during an implementation of Office 365, to avoid introducing a solution that causes revolting end-users and decreased business productivity.
CONSIDERATION #1 – KNOW THE MODERN ALTERNATIVES FOR SECURING CONTENT
While multi-factor authentication is often considered as “the silver bullet” when it comes to service access security measures, it is vital to understand the type of innovation that has been going on for the last 5-10 years, and with that the new kind of services that now are available that can protect the content rather than just limiting the access. Multi-factor authentication comes with a cost of complexity for the end-user, and you often find that for the kind of information most users handle day-to-day – multi-factor authentication is not required if an alternative is put to place instead (and there is a wide array of alternatives). Here is a list of example content protection solutions, part of Office 365 and/or EMS/Azure AD Premium, that could be a replacement for, or supplement to, multi-factor authentication:
- Azure AD Identity Protection: This service utilizes machine learning and anomaly reports to both present current risk events in your organization and to automatically act on them. As an example, the service can detect credential theft by analyzing log-on behavior (such as simultaneous logon attempts from different continents of the world) and automatically act to secure the account before data is at risk. It will also detect sign-in attempts from infected devices and suspicious IP-addresses, and even patrol the dark web for credentials that are leaked from your organization. Read about Azure AD Identity Protection here. Azure AD Identity Protection is a part of Azure AD Premium and EMS (where Azure AD Premium is included).
- Rights Management Services (RMS): Together with data sensitivity classifications, properly introduced RMS can move the protection from access-centric (i.e. VPN, MFA) to content-centric (encrypted content that keeps data secure even if breach/data loss occurs). Read more here. The standard version of RMS is included in Office 365 E3/E5 and as an add-on license, whilst the Premium version of RMS (RMS Premium) is a part of EMS or can be purchased as a standalone license.
- Office 365 Message Encryption (OME): For e-mail, this RMS-based technology can keep e-mail body and attachment secure, even when sending to external recipients. Read more here, and see my post about implementing OME here. Office 365 Message Encryption is part of the standard version of RMS (Office 365 E3/E5 or as an add-on license).
- Data Loss Prevention (DLP): This service fills two main purposes – it can prevent data to fall in to the wrong hands and it can help the organization to comply with business regulations, such as HIPAA, SOX, PCI DSS and FISMA. Data Loss Prevention can identify sensitive data in e-mail, SharePoint Sites and in OneDrive for Business and allows you to configure measures to be taken when it is at risk for leakage, such as applying RMS encryption or preventing an e-mail from being sent. Read more about DLP here. DLP is part of Office 365 E3/E5.
- Advanced Thread Protection (ATP): An intelligent remedy for zero-day attacks and spear-phishing. ATP is first released for e-mail in Exchange Online, but is expanding to Windows Defender and probably to other Office 365 workloads as well, eventually. ATP opens/executes e-mail attachments in a virtual machine and analyze it before delivering them to the recipient. The analysis will find ransomware such as CryptoLocker, or other types of malicious code that has not yet landed as a signature in the regular signature-based spam filter (Exchange Online Protection). ATP will also do the same type of test for any link that is in the e-mail, to protect the organization from spear-phishing. Read more about ATP for Exchange Online here, and ATP for Windows Defender here. ATP is part of Office 365 E5 or as a standalone license.
- Conditional Access: The concept of Conditional Access allows you to set device-based conditions for allowing or blocking access to your organizations data. The most common example of this is to require mobile devices to be enrolled (MDM), or mobile device applications to be registered (MAM), together with a policy enforcement of certain sanity requirements (i.e. PIN-code is enabled, device is not jail-broken or rooted etc.). Together with these policies, you can require multi-factor authentication for registering the device, but not later. This allows you to secure content through multi-factor authentication, but just require the mobile token upon device enrollment/MAM-registration, and then trust your security policies to secure the device. Conditional Access is also what allows you to enable multi-factor authentication for Office 365 services individually (i.e. enabling it for SharePoint Online, OneDrive for Business and Outlook/OWA, but not for ActiveSync or Skype for Business) – without Conditional Access, you have to enable MFA in Office 365 for all services or none. Read more about Conditional Access here and here. Basic functionality for Conditional Access is included in Office 365, while more advanced functionality (such as per-workload MFA) requires Azure AD Premium or EMS (where Azure AD Premium is included).
It is first when you understand the full palette of service access and content protection technologies available that you can take the right decision whether if, how and for whom Office 365 multi-factor authentication is needed and should be implemented for in your organization. Remember the two sides of the scale – ultimate usability vs. ultimate security.
CONSIDERATION #2 – THE INSIDE/OUTSIDE PARAMETER AND IT’S EFFECT
After looking into the alternatives, the next thing to consider about MFA is the inside/outside parameter. In most cases, MFA is something that should occur outside the corporate network, but not while at your desk inside the office firewall. To achieve this with Office 365, you must define your inside network by providing all public IP-addresses for your internet break-outs (firewalls and web proxies etc.). By providing all public break-out IP-addresses, Azure AD can at the time of authentication see whether you are attempting an authentication from the corporate network or in the mobile context, so that you can avoid bothering your end-users with MFA while at work. This configuration is called Trusted IPs (or contextual IP address whitelisting), and is also fundamental to the Conditional Access technology mentioned in this article.
The big consideration? If you are not using federated identities with ADFS, it requires one of the following licenses: Azure MFA, Azure AD Premium or EMS (that includes Azure AD Premium. If you are not using ADFS and don’t have any of these licenses, enabling MFA means enabling MFA everywhere – both in the office and outside the office. Read more here. If you are using federated identities / ADFS, you can achieve this even without any of the Azure MFA / Azure AD Premium / EMS if you are using claim rules – again see this post by MVP Johan Dahlbom for details. The post also explains the “Skip multi-factor authentication for requests from following range of IP address subnets” option.
CONSIDERATION #3 – THE IMPORTANCE OF AZURE AD CONDITIONAL ACCESS FOR SAAS
Under Consideration #1 above, you could read about Azure AD Conditional Access for SaaS. Without this service, multi-factor authentication for Office 365 becomes more complicated to implement in large enterprise environments. Without Conditional Access, you can only toggle multi-factor authentication on or off in Office 365 in one generic setting across the full suite, which includes Exchange Active Sync (mobile access to your e-mail and calendar using the built-in Mail apps in Android and iOS etc.). For Active Sync without Azure AD Conditional Access for SaaS (or ADFS claim rules, see below), the user is required to use something called App Passwords, which are secondary passwords that the user must generate per device in the web browser. The enrollment process for App Passwords is fairly complicated for an average user, and often require a lot of support from Service Desk and similar functions. App Passwords used to be required in the rich Office applications as well, but since the Office 2013 SP1 March 2015 update, you can use proper multi-factor authentication within Office (this version requirement for Office is a consideration in itself).
Using App Passwords for Active Sync in enterprise environments is not working very well in practice, which is why we want to avoid that. By using Azure AD Conditional Access for SaaS, we can choose to enable multi-factor authentication, but keep it “disabled” for Active Sync and instead trust device enrollment (MDM) or device registration in the Outlook app (MAM) to secure mobile e-mail access. If you are using federated identities (ADFS), you can also disable MFA for Active Sync by using claim rules in ADFS, which MVP Johan Dahlbom explains very well in this article. The claim rules solution will also work without Azure AD Premium / EMS.
As mentioned under Consideration #1, MFA can be required when doing MDM enrollment, or when accessing data using MAM – however the important thing here is that your end-users don’t have to enroll for App Passwords to be able to use e-mail and calendar on their phone. Note that the Microsoft Outlook app for iOS/Android/Windows 10 Mobile have support for MFA. Read more about Azure AD Conditional Access for SaaS Apps here.
CONSIDERATION #4 – MOBILE ACCESS TOKENS AND A GLOBAL USER BASE
The final consideration for implementing multi-factor authentication is to reflect your full user base, and how MFA will work for everyone. Here is a list of parameters to reflect:
- Data access and user profiles: Before enabling MFA, think about what data different users in different departments actually can access and is working with. Maybe a certain user profile can only access that is not so sensitive that it falls under the MFA requirement, and does not have to be enabled for MFA?
- Overall complexity and user profiles: After MFA is enabled for a user, he or she needs to go through an enrollment process. This process is often straight-forward for someone who spends their full day in front of the screen and reads corporate communications on changes to come. However, there are often user profiles who may have a very hard time to enroll for MFA because of lower it-maturity or interest etc. Do not underestimate the different skill levels across your full user base, and involve all user profiles when you pilot the enrollment process.
- Users and devices in developing countries: MFA in Azure AD / Office 365 is using mobile phones to deliver the access token to the user (via SMS text, phone call or through the Microsoft Authenticator app). In developing countries, not everyone is having a smart phone (for the Microsoft Authenticator app) or even a mobile or desktop phone (for SMS text or phone calls). If the user does not have a personal phone, Azure AD / Office 365 MFA is not a good fit. Also, in developing countries there are sometimes delays in delivering SMS text messages or even phone calls (I have seen cases with up to 8 hours of delayed delivery on SMS text messages caused by the local telephony service provider) – this factor is very important to take into consideration before enabling MFA for everyone.
- Office versions being used: As mentioned under Consideration #3 above, multi-factor authentication requires at least version “Office 2013 SP1 with the March 2015 update” to support proper multi-factor authentication prompts within the Office-applications, and not requiring the obsolete App Password technology. If you have user profiles that are on earlier versions of Office, you might need to do an extensive upgrade effort before you can implement MFA.
CONCLUSION AND GENERAL RECOMMENDATION
As you can see, there are many things to consider before enabling MFA in Office 365. Factors such as what licenses you have, where/who your users are and whether modern alternatives can meet the security requirements must all be taken in to account.
If you are going to enable multi-factor authentication, I strongly recommend you to do it only for the users who can access sensitive information, using Trusted IPs, and configure it to not use App Passwords for Active Sync (through Conditional Access or ADFS Claim Rules). For dealing with “credential theft”, consider Azure AD Identity Protection. As a last recommendation – pilot thoroughly for all your user profiles before introducing MFA globally.
I hope these considerations and recommendations are helpful. For any questions or article feedback, please reach out via Twitter, @JesperStahle.