What are Office 365 Client Access Policies?
Note: Some options described in this topic may be Early Access features which may not be available in your org. To enable them, contact Okta Support.
With Office 365 Client Access Policies, we extend the reach of these controls. Now, Okta allows you to set specific access requirements for different client types (desktop clients, mobile devices, and web browsers) that access Office 365 services.
In order to achieve this granular level of control, Okta leverages host headers sent from the client and from the Office 365 service to make access decisions based on the policies that you configure. These headers include details about:
Note: 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 that is detailed later in this guide.
You can deploy Office 365 Client Access Policies in your environment incrementally (by applying rules to groups and users) or across all users that access the application. It is important to thoroughly review this guide to ensure that the policies apply to your enterprise as you intend.
Where are Office 365 Client Access Policies configured?
Before you begin, ensure that you have an Office 365 application created in your Okta tenant, and that the application uses Single Sign-On (SSO). If you’re just getting started with Office 365, refer to our Office 365 Deployment Guide for setup instructions and configuration options.
Once you configure the application and SSO, you’re ready to get started with Office 365 Client Access Policies.
You can layer rules for Office 365 Client Access Policies to provide a tightly controlled user sign-on experience. User experience depends on the different components present in each of the rules.
Note: Depending on the configuration and features available in your Okta tenant, your user interface may vary. The ability to configure multiple Network Location Zones requires Okta’s Adaptive MFA SKU.
Looking at the App Sign On Rule above, consider the following configuration options when developing your own rules:
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 it is important to consider:
You can also scope rules to specific locations or zones. The Office 365 Client Access Policies work seamlessly with Okta’s Geographic Network and IP Zones that can be configured in the Okta Admin console within Security > Network.
In order to apply these rules, Okta relies on the IP Address(es) that are passed in the authentication request headers. It is recommended to include Microsoft's Exchange Online IP addresses (listed here) as Proxy IPs in your Network configuration. Consult our Network guide for details.
It is important to consider the impact of network zones when thinking about restricting access and prompting for MFA. The available options include:
The key to Office 365 Client Access Policies is the ability to distinguish different access based on the client that is accessing the Office 365 resource.
Note: Clients using Modern Authentication are treated as web browsers. Microsoft documents this limitation as part of Office Clients and the Office 365 service. Further detail is available from: http://go.microsoft.com/fwlink/p/?LinkId=717374
Client can refer to:
Device TrustNote: This is an Early Access feature. To enable it, contact Okta Support.
If enabled for your org, device trust settings allow you to gate access to apps depending on whether users' devices are trusted. For details, see Device Trust documentation.
Finally, specify the actions that should be taken if the user falls into scope of the rule specified above:
The key to selecting appropriate actions is deciding whether access should be Allowed or Denied.
Note: 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.
Note: 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 in order for the restrictions to take effect.
For thick clients supporting MFA, the individual application or service determines the frequency at which they are directed back to Okta for authentication. For Microsoft Office applications, these refresh intervals are documented in https://support.office.com/en-us/article/Session-timeouts-for-Office-365-37a5c116-5b07-4f70-8333-5b86fd2c3c40