Configure Office 365 sign-on rules to allow on-prem and cloud access
Once you’ve successfully federated your Office 365 domain in Okta, you need to configure a sign-on policy for the Office 365 app to allow both on-premises and cloud access.
User login requests authenticate against Azure AD to receive a Primary Refresh Token (PRT). This token is granted along with a Windows 10 device registration, and uses the WINLOGON service. However, the WINLOGON service uses legacy authentication, which is blocked by Okta’s default Office 365 sign-on policy. Therefore, you need to configure the Office 365 app-level sign-on policy to allow the WINLOGON service.
However, MFA can’t be enforced on legacy authentication requests, making it susceptible to cyber attacks such as password spray. Therefore, we recommend minimizing the use of legacy authentication.
This procedure involves the following tasks:
Configure sign-on rules in Okta
There are two ways in which you can allow Hybrid AAD joined devices to securely connect to Azure AD while minimizing the use of legacy authentication:
1. Allow only select user agent strings to use legacy authentication
You can filter specific trusted clients using the Office 365 app sign-on rules to allow them access to Office 365 resources, for example Windows-AzureAD-Authentication-Provider. It gives you a finer control over user agents that can access the Office 365 apps. See Allow or deny custom clients in Office 365 sign-on policy.
2. Allow legacy authentication only within local intranet and require MFA for non-locals
There are two parts in this procedure:
a. Allow legacy authentication only within local intranet
In your Microsoft tenant, disable all Microsoft services that use legacy authentication. Then, in Okta, modify the Office 365 app sign-on policy to allow legacy authentication only when the device is in the local intranet. See the following docs:
b. Require MFA while outside local intranet
If a user is using a device that is not on your local intranet, require them to successfully complete an MFA prompt before granting them access to Azure AD resources. In Azure AD, create a Conditional Access Policy that requires MFA for such users, and then in Okta, modify your Office 365 app setting to use Okta MFA to satisfy Azure AD MFA.
In this scenario, Azure AD redirects the user to Okta to complete the MFA prompt. Upon successful completion of the prompt, Okta passes the MFA claim to Azure AD, and then Azure AD allows the user to access the Microsoft resources. This streamlines the sign-in experience for the user as they have to complete only one MFA prompt. See Use Okta MFA for Azure Active Directory.
We recommend using a combination of Conditional Access Policy and Office 365 app sign-on policy to ensure wide security coverage. Okta enforces its sign-on policy at each sign-on event. After sign-on, Azure AD enforces its Conditional Access Policy at a regular interval to ensure that the access is secure.
Block legacy authentication on the Microsoft side
Once you’ve configured appropriate sign-on rules in Okta, create authentication policies in Microsoft to block legacy authentication for all Microsoft services. Assign these policies to users. See Disable Basic authentication in Exchange Online (Microsoft docs).