<iframe src="https://www.googletagmanager.com/ns.html?id=GTM-M74D8PB" height="0" width="0" style="display:none;visibility:hidden">
Loading
Skip to NavigationSkip to Main Content
Sign-On Policy Deny Events in Okta After Federating O365 App
Single Sign-On
Okta Classic Engine
Okta Identity Engine
Overview

This guide covers a system log event that may occur after federating with Okta: Evaluation of sign-on policy deny. When investigated further, the user agent is discovered to be "Windows-AzureAD-Authentication-Provider/1.0.”

This article addresses whether there is a way to set a policy to allow these logon events.
 

NOTE: Only add this kind of policy if it is required. Basic Auth bypasses Multi-Factor Authentication, so use it with caution.

System log

 

 
 
Applies To
  • Microsoft Office 365 (M365 / O365)
  • Web Services Federation (WS-Fed)
Solution

An Authentication Policy can be configured to allow this agent. To set up client access control for Microsoft Office 365 in the Okta Admin Console, follow these steps:
 

Okta Identity Engine (OIE) Steps

  1. In the Applications > Applications section, select the Microsoft Office 365 app.

  2. Click the Sign On tab.

  3. Under User authentication > Authentication policy, click View policy details.

    • Alternatively, it can be found by going to Security > Authentication Policies > Microsoft Office 365 > Add Rule.

user authentication

  1. On the Authentication Policies page, create a new Authentication Policy or edit an existing one.

  2. Within the rule, navigate to the If section and select The following custom expression is true.

  3. Enter a custom expression using Okta Expression Language to allow or deny access for the client.

    • For this specific issue, the custom expression would be: request.userAgent.contains("Windows-AzureAD-Authentication-Provider").
      Fill out other sections as necessary and save the changes. For further information, refer to the Office 365 sign-on rules options.

  4. Back in the Sign On Policy section, assign this rule a suitable priority level. Okta evaluates rules in order of priority and implements the first matching rule.

  5. Repeat these steps for each client who will be allowed or denied.

  6. By following these steps, specified clients can be filtered, conditions and actions defined in the rule can be applied, and control access to Office 365.

add rule

 

Okta Classic Engine Steps

  1. Navigate to Applications > Applications and select the Office 365 app from the list of app integrations.

  2. Click on the Sign On tab and find the Sign On Policy heading.

  3. Either click Add rule to add a new Sign On Policy or click on the pencil pencil icon icon to edit an existing policy.

  4. In the Client section > If the user's client is any of these, select Custom.

  5. Enter the below string value for the Windows Azure AD Authentication client.

    • Windows-AzureAD-Authentication-Provider/1.0.
      Okta_Classic_Engine_-_O365_custom_client_setup 

    • For example, please watch:


       

  6. Complete other sections as appropriate and click Save.

  7. Back in the Sign On Policy section, place this rule at an appropriate priority level. Okta evaluates each rule by priority and applies the first rule that matches.
     

Related References

 
Loading
Sign-On Policy Deny Events in Okta After Federating O365 App