Tag Archives: OME

Considerations for Meeting Multi-Factor Authentication Requirements in Office 365

BACKGROUND

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”.

CONSIDERATIONS

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:

  1. 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).
  2. 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.
  3. 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).
  4. 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.
  5. 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.
  6. 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.

Azure AD Identity Protection provides modern features to protect your corporate identities.

Azure AD Identity Protection provides modern features to protect your corporate identities.

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.

These are the settings where you can define the inside and outside of your corporate network. Important as you probably don't want to bother end-users with MFA prompts when working from the office.

These are the settings where you can define the inside and outside of your corporate network. Important as you probably don’t want to bother end-users with MFA prompts when working from the office.

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.

With Azure AD Conditional Access for SaaS, you can configure individual access rules for the different Office 365 workloads. Here is an overview of the settings available for Exchange Online.

With Azure AD Conditional Access for SaaS, you can configure individual access rules for the different Office 365 workloads. Here is an overview of the settings available for Exchange Online.

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:

  1. 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?
  2. 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.
  3. 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.
  4. 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.

Hands on with Office 365 Message Encryption (OME) using One Time Passcode

ARTICLE UPDATED OCTOBER 2014 AFTER LAUNCH OF OTP CAPABILITIES IN OME.

INTRODUCTION

At the beginning of 2014, Microsoft released new capabilities for email encryption, called Office 365 Message Encryption (OME). The functionality was first announced in november 2013 in this article. In October 2014, OME was improved drastically as the receiver of encrypted emails now can use a One Time Passcode (OTP) to access the encrypted message (documented here). At launch of OME, all receivers had to authenticate with either an Organizational Account (Azure AD) or a Microsoft Account (formerly LiveID) to access the email, which often led to confusion for external receivers. Now, the receiver can instead request a One Time Passcode to the same email address as to which the encrypted message was sent, and use that (within 15 minutes) to access the encrypted email. This post was updated in October 2014 to include this new OTP-functionality.

In this post, I will demonstrate the user experience of Office 365 Message Encryption, both for the end-user (using OTP) and the administrator (setting up IRM Licensing and all necessary Transport Rules etc).

SCENARIO

We will create a transport rule that will enable Office 365 Message Encryption on messages with a Sensitivity level set to Confidential.

STEP 1 – ENABLE IRM LICENSING

If you attempt to use Office 365 Message Encryption before first enabling IRM licensing, the operation will fail and give you this message:

You can’t create a rule containing the ApplyOME or RemoveOME action because IRM licensing is disabled.

To remediate this, we need to enable IRM licensing using the Admin portal and PowerShell. Follow these steps:

  1. First, enable RMS in your tenant by logging on to your Office 365 Admin Portal, navigate to Service settings (left pane). select Rights management (top bar), click Manage and finally hit the button Activate. A message should appear stating that RMS is activated for the tenant.
  2. The remaining steps will be done in PowerShell. Open Windows Azure Active Directory Module for Windows PowerShell, found here:
    http://technet.microsoft.com/library/jj151815.aspx
  3. Connect your PowerShell session to your Office 365 tenant an Exchange Online by entering the following:
    $msolcred = Get-Credential (Answer the credential prompt with your Office 365 tenant administrator credentials) 
    Connect-MsolService -Credential $msolcred

    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $msolcred -Authentication Basic -AllowRedirection
    Import-PSSession $Session
  4. When connected to Exchange Online, you can enable IRM licensing with just a few steps. The first step is to set the RMS Online key sharing location. You will use different configurations depending on where your tenant is located (North America, European Union or the Asia-Pacific area).Enter the command that matches your tenant location (choose one):
    North America: Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.na.aadrm.com/TenantManagement/ServicePartner.svc
    European Union: Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.eu.aadrm.com/TenantManagement/ServicePartner.svc
    The Asia-Pacific Area: Set-IRMConfiguration -RMSOnlineKeySharingLocation https://sp-rms.ap.aadrm.com/TenantManagement/ServicePartner.svc
  5. After setting the key sharing location, the next step is to import the Trusted Publishing Domain (TPD). Do so by entering the following:
    Import-RMSTrustedPublishingDomain -RMSOnline -name “RMS Online”
  6. The final step is to activate the internal IRM licensing. Do so by entering the following:
    Set-IRMConfiguration -InternalLicensingEnabled $True
  7. After enabling IRM licensing, verify the functionality by entering:
    Test-IRMConfiguration -RMSOnline

The test should pass with the result OVERALL RESULT: PASS.

NOTE: Enabling IRM licensing might need several hours for the change to take effect. If possible, allow 8 hours to pass before proceeding with STEP 2.

STEP 2 – CREATE THE OME TRANSPORT RULE

We will create a transport rule that enables Office 365 Message Encryption if the message is sent to a recipient outside the organization and the Sensitivity header have been set to Confidential.

Follow these steps:

  1. Log in to your Office 365 Admin Portal and navigate to Exchange Control Panel (Admin\Exchange).
  2. Navigate to Mail Flow, click the + icon and select Create a new rule…
    Newrule
  3. Give the rule a suiting name and click More options…
    moreoptions
  4. From here you can set your condition as it fits your needs, but for this example we will inspect the Sensitivity header and apply Message Encryption based on that. To do so, select the following conditions:
    Apply this rule if… A message header includes any of these words
    amessageheader
  5. Complete the Apply this rule if-condition by clicking the properties Enter text and Enter word so that the condition makes ‘Sensitivity’ header includes ‘Confidential’
    sensincl
  6. Click Add condition and select The recipient… Is external/internal. Click Select one… and select Outside the organization and hit OK
    outside
  7. Proceed with clicking Do the following… and select Modify the message security… and select Apply Office 365 Message Encryption
    applyo365m
  8. Hit Save at the bottom of the New rule editor. (If you get the message that IRM licensing is not enabled and have completed STEP 1 – please allow more time for the change to take effect, as stated in the Note after STEP 1).

STEP 3 – SEND A CONFIDENTIAL MESSAGE WITH OME

We will create a message with the sensitivity level set to Confidential and send this to a recipient outside our organization. Our transport rule will apply Office 365 Message Encryption to the message.

Follow these steps:

  1. Open Outlook or Outlook Web App. Both clients have the native functionality to set the sensitivity header. In the example, I will use OWA, but the procedure is the same in Outlook.
  2. Compose a new message. Enter an external recipients, give the message a subject and some content, then click  and Show message options…
    messageopt
  3. Set the message Sensitivity level to Confidential and hit OK
    confidential
    NOTE: In the rich Outlook client, Sensitivity options are found under Message Options\More options\Sensitivity.
  4. Send the message.

STEP 4 – RECEIVE AND OPEN THE ENCRYPTED MESSAGE

  1. Open the inbox of the external mailbox and find the encrypted message
    protectedmessage
  2. As you can see, the message includes an attached HTML-document. Open the attachment.
  3. To be able to read the encrypted message, you can choose to sign in with a Microsoft Account or Corporate Credentials (AAD/Office 365 account) that has a username that matches the e-mail address to which the encrypted message was sent – or (new October 2014) you can choose to open the message with a One Time Passcode that is sent to the same email address that received the encrypted message (html file). I recommend using Organizational Accounts when sending to other Office 365 users, as they can then open the message with their corporate credentials or even an existing session cookie (Single Sign-on experience) – but for external users, which we are demonstrating in this case, One Time Passcode would be prefered. I am selecting the OTP choise by following the link at the bottom (“Don’t want to sign in? Get a one-time passcode…”).
    Select "Get a one-time passcode..."
  4. Now, go back to your inbox (recipient) to find the One Time Passcode and a reference code (handy if you have received multiple encrypted messages at once to differentiate the OTPs for different messages). Make a note of the OTP and go back to the browser.
    Find the OTP in your inbox
  5. Enter the Passcode from the email in the Passcode field, then click Continue.
    step2
  6. The message will now load and be displayed in the browser.
    voila

CONCLUSION

The Office 365 Message Encryption is a very good feature that allows Office 365/Exchange Online customers to send encrypted messages both inside and outside their organization. The new OTP functionality makes it even better and more complete. This post demonstrated the basic capabilities of OME, and you can make even more advanced Mail Rules, such as applying RMS templates to the message if it is sent to an internal recipient, and use Office 365 Message Encryption only to external recipients – just configure the rule to fit your needs.

You can also customize/brand the message that includes the HTML-file by using the
Set-OMEConfiguration cmdlets. The cmdlets allow you to set custom e-mail text, disclaimer, portal text and even include your company logo for branding.