Office 365 Client Access Policies
Okta policies allow you to restrict access to your applications in various ways, including network location, group membership, and/or multifactor authentication (MFA). With Office 365 (O365) clientEssentially, a client is anything that talks to the Okta service. Within the traditional client-server model, Okta is the server. The client might be an agent, an Okta mobile app, or a browser plugin. access policies, you can extend the reach of these controls. Okta allows you to set specific access requirements for the following client types that access O365 services:
- Originating IP Address
- Web browser
- Modern authentication client
- Exchange ActiveSync client
- Modern authentication supported mobile apps (iOS, Android, other mobile)
In order to achieve this granular level of control, Okta leverages host headers sent from the client and O365 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 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 O365 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.
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-AgentA software agent is a lightweight program that runs as a service outside of Okta. It is typically installed behind a firewall and allows Okta to tunnel communication between an on-premises service and Okta's cloud service. Okta employs several agent types: Active Directory, LDAP, RADIUS, RSA, Active Directory Password Sync, and IWA. For example, users can install multiple Active Directory agents to ensure that the integration is robust and highly available across geographic locations. request header sent from the usersIn Okta literature, we generally refer to "users" as the people who serve as Okta administrators. When we refer to "end users" we are generally referring to the people who the administrators serve. That is, those who use Okta chiclets to access their apps, but have no administrative control.’ browser. Because the User-Agent can be spoofed by a malicious actor, you should consider using a whitelist approach when you create CAPs and require MFA or Device Trust as described in the following best practices:
- Implement a whitelist 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 appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in..
- 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.
- 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. For more on this issue, see <Security team doc>.
You can deploy O365 client access policies in your environment incrementally (by applying rules to users and/or user groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with 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 O365 app created in your Okta tenant, and ensure that it is configured for SSOAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones.. If you’re just getting started with O365, refer to our Office 365 Deployment Guide for setup instructions and configuration options.
Note the following when creating new rules:
- The Default sign on rule allows access to all clients from any network without requiring MFA. This cannot be modified.
- Starting from Priority 1 to the final rule, Okta evaluates each rule by priority. Okta then applies the first rule that matches. If a user does not fall within the scopeA scope is an indication by the client that it wants to access some resource. of a preceding rule (or rules applied globally across the tenant), they are subject to the Default sign on rule allowing access to O365 services.
You can layer rules for O365 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 AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Dashboard, hover over Applications drop-down menu.
- On the Applications page, scroll down to the O365 app instance and click the app.
- Click the Sign On tab. Scroll down to Sign On Policy.
- Click the Add Rule button. 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.
You can scope O365 client access policies to all users accessing the O365 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 O365 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 O365 deployment.
You can scope rules to specific locations or zones. The O365 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.
One benefit to O365 client access policies is that they allow you to manage access based on the client that is requesting the O365 resource.
Note: Clients using Modern Authentication client are treated as Web browsers. Microsoft documents this limitation as part of MS Office Clients and the O365 service. For details, refer to this MS Support documentation: MS TechNet: Things to know before onboarding.
Web browser or Modern Authentication client: Includes browsers such as Chrome, Safari, or Internet Explorer, as well as 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.
Note: Modern Authentication is a configurable setting on the O365 tenant for Exchange Online. For more information about configuring this setting, refer to these Microsoft articles:
Exchange ActiveSync or Legacy Auth client: 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.
- 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.
- MS Windows
- Other desktop OS platforms such as Linux
This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, please contact Okta Support.
If enabled for your orgThe Okta container that represents a real-world organization., Device Trust settings allow you to gate access to apps depending on whether devices are trusted. For details, see Device Trust documentation:
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.
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.Top