Windows workstation logins fail after federating Microsoft Office 365 (O365) with Okta because the default sign-on policy denies legacy authentication requests from the WINLOGON service. Configure the O365 application sign-on policy to allow the specific user agent to resolve this issue. Users are unable to log in to Windows operating system workstations. The Okta System Log displays an Evaluation of sign-on policy deny event for the affected usernames during the Windows login attempt. Expanding the debug context of the System Log event reveals the user agent string Windows-AzureAD-Authentication-Provider/1.0..

• Okta Identity Engine (OIE)
• Okta Classic Engine
• Microsoft Office 365 (O365)
• Web Services Federation (WS-Fed)
• Windows 10 and Windows 11 workstation login (Hybrid Azure Active Directory (AD) Join / Azure AD Join)

Windows 10 and Windows 11 devices that use Azure AD Join or Hybrid Azure AD Join authenticate to Microsoft Entra ID (Azure AD) to obtain a Primary Refresh Token (PRT) during workstation login. This process relies on the WINLOGON service, which uses a legacy authentication call rather than modern, browser-based authentication. By default, the Okta O365 application sign-on policy only permits access using modern-authentication-compatible protocols. Okta evaluates the WINLOGON request presenting the user agent Windows-AzureAD-Authentication-Provider/1.0 as legacy authentication and denies the request unless a rule explicitly allows it.

NOTE: Okta cannot enforce multi-factor authentication (MFA) on legacy authentication requests, which makes allowing this user agent a potential security tradeoff. Only implement this exemption if the organization requires Hybrid/Azure AD-joined Windows login via Okta, and scope it as tightly as possible.

How does an administrator configure the sign-on policy in Okta Identity Engine?

Add a rule to the O365 authentication policy in the Okta Admin Console to allow the Windows Azure AD authentication provider using a custom expression.

1. In the Admin Console, navigate to Applications > Applications and select the Microsoft Office 365 application integration.
2. Select the Sign On tab.
3. Under User authentication > Authentication policy, select View policy details.
4. Select Add Rule.
5. Enter an appropriate name for the rule.
6. In the IF section, select The following custom expression is true and enter the following expression:

request.userAgent.contains("Windows-AzureAD-Authentication-Provider")

7. Configure the THEN section according to the security posture of the organization.
8. Select Save.
9. Prioritize this rule above any catch-all or deny legacy authentication rules.

Configure the sign-on policy in Okta Classic Engine

Add a custom client rule to the O365 sign-on policy in the Okta Admin Console to allow the Windows Azure AD authentication provider.

1. In the Admin Console, navigate to Applications > Applications and select the Microsoft Office 365 application integration.
2. Select the Sign On tab and locate the Sign On Policy section.
3. Select Add Rule.
4. Enter an appropriate name for the rule.
5. Under Client, set If the user's client is any of these to Custom.
6. Enter the exact user agent string: Windows-AzureAD-Authentication-Provider/1.0.
    

• • For example, please watch:
    
    
     

7. Complete the remaining conditions and actions as needed.
8. Select Save.
9. Reorder the rule so it sits above stricter deny rules.

How does an administrator verify the resolution?

Verify the fix by attempting a Windows login and reviewing the Okta System Log for a successful policy evaluation.

1. Attempt a Windows login with an affected user account.
2. Confirm the System Log displays an Evaluation of sign-on policy ALLOW event instead of a DENY event.
3. Confirm the rule match by checking that the debug context on the log event references the new rule name.

Related References

• Configure Office 365 sign-on rules to allow on-prem and cloud access (OIE)
• Configure Office 365 sign-on rules to allow on-prem and cloud access (Classic)
• Office 365 sign-on rules options (OIE)
• Allow or deny custom clients in Office 365 sign-on policy (Classic)
• Allow or deny custom clients in Office 365 sign-on policy (OIE)
• Best security practices for Office 365 sign on policies