Okta Office 365

Each year Okta processes millions of SaaS logons via its authentication system. It kindly aggregates that data to find the most popular apps and publishes an annual report. This year it found that the most popular tool by far was Microsoft Office 365.

Okta Office 365 Ios
Okta Office 365 Provisioning
Okta Office 365 Provisioning

It's worth noting that while app usage popularity varied by region, Office 365 was number one with a bullet across the board, whether globally or when the report broke it down by geographic area. That wasn't true of any other product in this report, so Office 365 has extensive usage across the world (at least among companies that use Okta).

Okta recently hosted a webinar focused on Office 365 Provisioning. Watch the recording to learn about O365 identity management, how to leverage Okta for O365. All Delta College students will use Okta, a single sign-on service, to log in to your student email, all Office 365 apps, and Canvas. Okta allows you to sign-in one time, and have access to several tools. From your Okta Dashboard, you will be able to access your email (through Outlook), all other Office 365 apps, and eventually Canvas.

But as with everything cloud, it's not a simple matter to say that because lots of people signed onto Office 365, Microsoft is the clear winner in a broader sense. In reality, the cloud is a complex marketplace, and just because people use one tool doesn't preclude them from using tools that compete directly with it.

As a case in point, consider that the report found that 36% of Microsoft 365 customers were also using Google Workspace (formerly known as G Suite), which offers a similar set of office productivity tools. Further, Okta found that 42% of Office 365 customers were using Zoom and 32% were using Slack.

Rapidly deploy Office 365 organization-wide and increase end-user adoption. Okta Cloud Connect integrates Office 365 with Active Directory/LDAP for fast and free single sign-on and provisioning. No more password reset fiascos. No more profile synchronization challenges. Microsoft 365 enables saving documents in the Cloud using OneDrive and SharePoint. Users can also access the Microsoft 365 applications on mobile devices through mobile apps or access through any browser using Office for the web. Using Okta Verify to access Microsoft 365 Desktop Applications OneDrive. Microsoft 365 consists of various Microsoft applications including Outlook, Teams, and OneDrive as well as Office Apps like Word, Excel, and PowerPoint. Microsoft 365 enables saving documents in the Cloud using OneDrive and SharePoint.

This is pretty remarkable when you consider that Office 365 bundles Teams with similar functionality for free. What's more, so does Google with Google Hangouts, so people use the tool they want when they want, and sometimes it seems they use competing versions of the same tool. The report also found that of those Office 365 users, 44% are using Salesforce, 41% AWS, 15% Smartsheet and 14% Tableau (which is owned by Salesforce). Microsoft has products in all those categories.

Microsoft is clearly a big company with a lot of products, but the report blows a hole in the idea that because people like Office 365, they are going to be big fans of other Microsoft products, or that they can count on any kind of brand loyalty across the range of products or even exclusivity within the same product category.

All of this, and much of the other data in this report makes tremendously interesting reading as far as it goes. It's not a definitive window on the state of SaaS. It's a definitive reading on the state of Okta customers' use of SaaS, on the Okta Integration Network (OIN), a point the company readily acknowledges in the report's methodology section.

'As you read this report, keep in mind that this data is representative of Okta’s customers, the applications and integrations we connect to through the OIN, and the ways in which users access these tools through our service,' the report stated.

But it is a way to look at the state of SaaS taking advantage of the 9400 Okta customers using the network and the 6500 integrations to the world's most popular SaaS tools. That gives the company a unique view into the world of SaaS. What you can conclude is that the cloud is complicated, and it's not a zero sum game by any means. In fact, being a winner in one area is not a guarantee of winning across the board.

Important Security Note

Legacy email protocols such as IMAP and POP are not capable of processing client access policies or MFA. This can present a significant security risk, as potential attackers who acquire user credentials will not be challenged for MFA if they use a legacy protocol. To disable these legacy protocols in your Office 365 tenant, refer to this Microsoft (MS) Support documentation: How to enable or disable POP3, IMAP, MAPI, Outlook Web app or Exchange ActiveSync for a mailbox in Office 365.

Okta policies allow you to restrict access to your applications based on end-user network location, group membership, and/or their ability to satisfy multifactor authentication (MFA) challenges. Office 365 client access policies allow you to extend the reach of these controls by specifying access requirements for the following client types that access Office 365 services:

Originating IP Address
Web browser
Modern authentication client
Exchange ActiveSync client
Modern authentication supported mobile apps (iOS, Android, other mobile)

To achieve this granular level of control, Okta leverages host headers sent from the client and Office 365 service to make access decisions based on the policies that you configure. Okta determines the client type by reading the request header. The client writes the header, which is responsible for its accuracy. Okta provides flexibility to inspect these headers as part of our System Log functionality.

Important to know about the User-Agent

Okta’s Client Access Policies (CAPs) allow you to manage access to your enterprise apps based on the client type and device platform. Okta CAPs evaluate information included in the User-Agent request header sent from the users’ browser. Because the User-Agent can be spoofed by a malicious actor, be aware that such actors may target the least restrictive CAP rule(s) in your policies. For this reason, make sure that your CAP rules comply with your company's security needs. Consider using an allowlist approach when you create CAPs and require MFA or Device Trust as described in the following best practices:

Implement an allowlist consisting of one or more rules that specify the client type(s) + device platform(s) + trust posture combinations that will be allowed to access the app.
Require Device Trust or MFA for app access.
Include a final catch-all rule that denies access to anything that does not match any of the CAPs preceding rules.

Best Practices

Okta recommends that you configure Office 365 client access policies to only allow MFA-supported protocols. Enforcing MFA ensures a robust security framework.
Ensure that your end-users are using the most up-to-date app versions, especially for thick clients such as Microsoft Outlook.

Rule Configuration

Important Security Note

You can deploy Office 365 client access policies in your environment incrementally (by applying rules to users and/or user groups) or across all users that access the app.

Before you begin, do the following:

Ensure that you thoroughly review this guide to accurately and safely apply these security policies.
Have an Office 365 app created in your Okta tenant and ensure that it is configured for SSO. If you’re just getting started with Office 365, refer to Typical workflow for deploying Microsoft Office 365 in Okta for setup instructions and configuration options.

Note the following when creating new rules:

The Default sign on rule denies access to all clients from any network. This cannot be modified.
Above the Default sign on rule is an Okta-provided rule that allows access to only web browsers and apps that support Modern Authentication. This rule is designed to help customers implement more secure policies by default.
Okta evaluates each rule by priority and applies the first rule that matches. If a user does not fall within the scope of a preceding rule (or rules applied globally across the tenant), they are subject to the Okta-provided rule followed by the Default sign on rule allowing access to Office 365 services.

You can layer rules for Office 365 client access policies to provide a more tightly controlled user sign-on experience. This user experience is dependent on the components configured within the rules.

To create your rules, do the following:

From the Admin Dashboard, hover over Applications drop-down menu.
On the Applications page, scroll down to the Office 365 app instance and click the app.
Click the Sign On tab.Scroll down to Sign On Policy.
Click Add Rule. The App Sign On Rule page appears.
Give a descriptive name for your rule.
Configure the desired conditions for the rule.

Note: Depending on the configuration and features available in your Okta tenant, your user interface may vary.

People

You can scope Office 365 client access policies to all users accessing the Office 365 application, or you can break them down to a subset of users/groups.

When configuring these rules you should consider who they should apply to

All users accessing the Office 365 app OR
Only a subset of users or groups

Consider scoping the rule to groups or a subset of users if:

There is a requirement to enable exceptions for application access.
There is a need to slowly phase these sign-on rules into an existing Office 365 deployment.

Location

You can scope rules to specific locations or zones. The Office 365 client access policies work seamlessly with Okta’s geographic network and IP Zones. These options can be configured in Okta under Security > Networks.

In order to apply these rules, Okta relies on the IP Address(es) that are passed in the authentication request headers. Okta recommends including Microsoft Exchange Online IP addresses as proxy IPs in your network configuration.

It is important to consider the impact of network zones when restricting access and prompting for MFA.

Anywhere: Apply this rule to all users regardless of where the access is originating.
In Zone: Apply this rule to users coming from a specific location or IP range. Consider a branch office in a location with unreliable security, for example. You may make MFA a consistent requirement from this location.
Not in Zone: Apply this rule to anyone not coming from a specific location or IP range. As an example, you may have corporate offices configured as a network location in Okta. You may require that MFA is always enforced when users are not coming from one of these known networks.

Client

One benefit to Office 365 client access policies is that they allow you to manage access based on the client that is requesting the Office 365 resource.

Client type

Web browser: Includes browsers such as Chrome, Safari, or Internet Explorer.
Modern Authentication: Includes thick client applications configured to leverage Modern Authentication. This includes Office 2013 and 2016 clients with required patches or configuration updates, as detailed in this MS Support documentation: Updated Office 365 modern authentication. Modern Authentication is a configurable setting on an Office 365 tenant for Exchange Online. See Microsoft documentation: Enable or disable modern authentication in Exchange Online and Office 365: Enable Modern Authentication.
Exchange ActiveSync or Legacy Auth: Includes native mail clients on iOS or Android devices, as well as older desktop clients on macOS and MS Windows that do not support Modern Authentication. Exchange ActiveSync or Legacy Auth client do not support multifactor authentication.
Custom: Specify a client to allow or deny it access to Office 365. This filter can be used to deny access to untrusted clients or to only allow trusted clients. See Allow or deny custom clients in Office 365 sign on policy.

Okta Office 365 Ios

Platform type

Mobile:

iOS
Android
Other mobile options. Select this option for:
- Non-iOS and non-Android clients such as Blackberry.
- Client types for which Okta cannot determine the operating system type by inspecting the request header. For example, when using an Outlook mail app on an iOS or Android device, the request header contains both iOS and Android. Selecting Other allows the client access policy to evaluate requests from these clients.

Desktop:

MS Windows
macOS
Other desktop OS platforms such as Linux

Device Trust

If enabled for your org, Device Trust settings allow you to gate access to apps depending on whether devices are trusted. For details, see Device Trust documentation.

Okta Office 365 Provisioning

Access

Finally, when all the conditions set above are met, specify the actions to be taken if a user triggers a rule.

Specify whether the conditions you've set allow access to be Allowed or Denied:

You can deny access if a user is coming from a risky or unknown network location.
You can set a requirement to prompt the user to re-authenticate after a set amount of time has elapsed after the app has launched.
You can prompt the user to perform MFA when signing into the app.

Please also note the following:

Okta enforces Sign On policies when a client is directed back to its Okta org. For browser-based clients, this generally occurs when the session is terminated by closing the browser or clearing cookies.
For desktop clients (not using Modern Authentication) and Exchange ActiveSync clients, an authenticated session is cached for up to 24 hours within the Microsoft service. After configuring client access policies to restrict these client types, it may take up to 24 hours for the restrictions to take effect.

Okta Office 365 Provisioning

For thick clients supporting MFA, the individual app or service determines how frequently they are directed back to Okta for authentication. For MS Office apps, refer to this MS Support documentation, Session timeouts for Office 365, for refresh intervals.