Get started with Office 365 sign on policies
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, 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 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.
- 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.
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:
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.
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.
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.
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.
- 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.
- 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
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.
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.