Securing Office 365 with Okta

Download

Background

As the leading independent provider of enterprise identity, Okta integrates with more than 5500+ applications out-of-the-box. Most of these applications are accessible from the Internet and regularly targeted by adversaries. Okta’s security team sees countless intrusion attempts across its customer base, including phishing, password spraying, KnockKnock, and brute-force attacks. They continuously monitor and rapidly respond to these attacks to protect customer tenants and the Okta service. The most commonly targeted application for these attacks is Office 365, a cloud business productivity service developed by Microsoft.

Okta’s customers commonly use a combination of single sign-on (SSO), automated provisioning, and multi-factor authentication (MFA) to protect their Office 365 tenants against the aforementioned attacks. However, Office 365 uses several authentication methods and access protocols, including options that do not support MFA in their authentication flow. It has become increasingly common for attackers to explore these options to compromise business email accounts.

This document covers the security issues discussed above and provides illustrative guidance on how to configure Office 365 with Okta to bridge the gap created by lack of MFA for Office 365. This information is based on internal research performed by the Okta security team and does not constitute a replacement for Okta documentation addressing Office 365 configuration for Okta.

Terms & Definitions

Authentication Methods

A. Basic Authentication
Basic Authentication, in the Office 365 suite, is a legacy authentication mechanism that relies solely on username and password. It has proven ineffective and is not recommended for the modern IT environments especially when authentication flows are exposed to the internet as is the case for Office 365.

B. Modern Authentication
To address the common security concerns and end-user experience requirements associated with Office 365 deployments, Microsoft introduced the Active Directory Authentication Library (ADAL) for Office 365 client applications, referred to as Modern Authentication. Modern Authentication helps secure Office 365 resources using multi-factor authentication, certificate-based authentication, and SAML-based logins (such as federation with Okta), for a true single sign-on experience.

Access Protocols

Office 365 supports multiple protocols that are used by clients to access Office 365. In the context of this document, the term “Access Protocol” indicates the protocols such as POP, IMAP, Exchange ActiveSync, Exchange Web Services (EWS), MAPI and PowerShell. In the context of authentication, these protocols fall into two categories: Access Protocols

A. Legacy Authentication Protocols
Protocols like POP and IMAP, which do not support modern authentication methods are referred to as legacy authentication protocols.

B. Modern Authentication Supported Protocols
Protocols like, Exchange ActiveSync, EWS, MAPI, and PowerShell, which support both basic and modern authentication methods are classified as modern authentication protocols, in the context of this document.

New Device Access Email Notification

Okta supports a security feature through which a user is notified via email of any sign-on that is detected for their Okta user account from a new device or a browser. The email provides information about the timestamp, location, and device information, such as IP Address and user agent (OS version/browser).

Office 365 Client Access Policies

Okta provides an approach to enable per-application sign-on policy to make access decisions based on group membership, network locations, platform (desktop or mobile), and multi-factor authentication, to name a few. However, with Office 365 client access policies, the access decision can also be implemented based on client type, such as web browser, modern auth or legacy auth clients. For more details refer to Getting Started with Office 365 Client Access Policy.

Introduction

Office 365 email access is governed by two attributes: an authentication method and an access protocol. Email clients use a combination consisting of one of each of the two attributes to access Office 365 email. It is important for organisations to be aware of all the access protocols through which a user may access Office 365 email, as some legacy authentication protocols do not support capabilities like multi-factor authentication. Table 1 summarises the list of Office 365 access protocols and the authentication methods they support.

 

Table 1: Protocol and supported authentication methods.

Note that ‘PowerShell’ is not an actual protocol used by email clients but required to interact with Exchange. Figure 1 below shows the Office 365 access matrix based on access protocols a