Office 365 sign-on rules options

This topic explains conditions and actions available for Office 365 app sign-on rules.

Conditions

Select under what conditions this rule will apply.

People

This section determines to whom the sign-on rule will apply. You can choose from the following options:

Option What it does
Users assigned this app Applies the rule to the users who are assigned this app
The following groups and users

Applies the rule to specific groups and users who are assigned this app.

To exclude specific groups and users from the rule, select Exclude the following users and groups from this rule and then specify groups and users.

 

Tip

Tip

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

  • You want to enable exceptions for the app access.
  • You want to slowly phase the sign-on rules in to an existing app.

Location

This section determines to which location the sign on rule will apply. If you are applying the rule to specific zones, you first need to set up Network Zone in Okta. See Network Security. Also consider the impact of network zones when restricting access.

You can choose from the following options:

Option What it does
Anywhere Applies the rule to all users regardless of where the access is originating
In Zone

Applies the rule to users coming from a specific location or IP range. For example, a branch office in a location with unreliable security. You may make MFA a consistent requirement from this location.

Not in Zone Applies this rule to anyone NOT coming from a specific location or IP range. For 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

The Client Type section determines to which clients the sign on rule will apply. You can choose from the following options:

Option What it does
Web browser Applies the rule to web browsers such as Chrome, Safari, or Internet Explorer.
Modern Authentication

Applies the rule to 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 Microsoft 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/ Legacy Authentication Applies the rule to 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.

The Platform Type section determines to which platforms the sign on rule will apply. You can choose from the following options:

Option What it does
iOS Applies the rule to the users coming from an iOS device.
Android

Applies the rule to the users coming from an Android device.

Other mobile

Applies the rule to the users coming from non-iOS and non-Android devices. For example, Blackberry.

Also useful for client types for which Okta can't 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 mobile allows the rule to evaluate requests from these clients.

Windows Applies the rule to the users coming from a Windows device.
macOS Applies the rule to the users coming from a macOS device.
Other desktop Applies the rule to the users coming from clients other than Windows and macOS. For example, Linux.

 

Device Trust

If Device Trust is enabled for your org, these settings allow you to manage access to apps depending on whether a device is trusted. See Okta Device Trust solutions.

Actions

Select what actions should be taken when the conditions set in a rule are met. For example:

  • 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.

Access

This section determines the actions that will be taken when all conditions set in the sign on rule are met. If you are requiring the user to complete MFA before accessing the app, you first need to set up MFA in Okta. See © 2021 Okta, Inc All Rights Reserved. Various trademarks held by their respective owners.. Also consider the impact of network zones when prompting for MFA.

You can choose from the following options:

Option What it does
Allowed Allows access when all conditions set in the sign on rule are met.
Denied Denies access when all conditions set in the sign on rule are met.
Prompt for re-authentication For SAML apps only, specifies how frequently the user will be prompted to re-authenticate. The time period you specify begins from the moment the user last authenticated into Okta.
Prompt for factor Requires the user to successfully complete the MFA prompt and specifies how frequently the user will be prompted for MFA.
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.

  • For desktop clients (that is 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 Microsoft Office apps refresh intervals, see Session timeouts for Office 365.

Related topics

  • Best security practices for Office 365 sign on policies
  • Office 365 default sign on rules
  • Create Office 365 sign on rules