Use Okta MFA to satisfy Azure AD MFA requirements for Office 365

This is an Early AccessEarly Access (EA) features are opt-in features that you can try out in your org by asking Okta Support to enable them. Additionally, the Features page in the Okta Admin Console (Settings > Features) allows Super Admins to enable and disable some EA features themselves. feature. To enable it, use the Early Access Feature Manager as described in Manage Early Access and Beta features .

You can use Okta multi-factor authentication (MFA) to satisfy the Azure AD MFA requirements for your WS-Federation Office 365 appAn abbreviation of application. Essentially, it is a web-based site used to perform any number of specific tasks, and requires authentication from end users by signing in. instance.

Okta MFA can be used in the following use-cases:

 

Known issues

Users can enter infinite sign-in loop when Okta sign-on policy is weaker than the Azure AD policy

A. This happens if neither the orgThe Okta container that represents a real-world organization.-level or the app-level sign-on policy requires MFA.

In this case, Okta does not prompt the user for the MFA. However, Azure AD Conditional Access requires MFA and expects Okta to pass the completed MFA claim. Consequently, the user gets stuck in the infinite authentication loop.

 

B. This can also happen when the sign-on policy doesn’t require the MFA when the user signs in from an in Zone network but requires the MFA when the user signs in from a network that is Not in Zone.

In this case, if the user is signing in from a network that’s In Zone, he or she will not be prompted for the MFA. However, Azure AD Conditional Access requires MFA and expects Okta to pass the completed MFA claim. Consequently, the user gets stuck in the infinite authentication loop.

 

Okta inadvertently passes successful MFA claim to Microsoft when user is excluded from the MFA requirement

This happens when the Office 365 sign-on policy excludes certain end users (individuals or groupsGroups allow you to organize your end users and the apps they can access. Assigning apps to large sets of end users is made easier with groups.) from the MFA requirement.

In this case, the user is not prompted for the MFA. However, Okta sends a successful MFA claim to Azure AD Conditional Access as the policy is set up to allow this user to sign in without completing the MFA. Azure AD Conditional Access accepts the Okta MFA claim and allows the user to sign in without requiring them to complete the MFA.

Prerequisites

  1. Configure MFA in Okta

    Do either or both of the following, depending on your implementation:

    1. Configure an org-level sign on policy as described in Multifactor Authentication .
    2. Configure an app sign on policy for your WS-Federation Office 365 app instance as described in Office 365 Client Access Policies.
  2. Configure MFA in Azure AD

    Configure MFA in your Azure AD instance as described in the Microsoft documentation.

  3. Enable this feature in Okta EA Feature Manager

    Enable Office 365 Pass Claim For MFA feature in Okta EA Feature Manager as described in Manage Early Access and Beta features .

Procedure

Once you have completed the prerequisites, you need to change the Office 365 domain federation settings to enable the support for Okta MFA.

If you've manually federated the domain

Run the updated federation script from under the Setup Instructions:

  1. From the Okta AdminAn abbreviation of administrator. This is the individual(s) who have access to the Okta Administrator Dashboard. They control the provisioning and deprovisioning of end users, the assigning of apps, the resetting of passwords, and the overall end user experience. Only administrators have the Administration button on the upper right side of the My Applications page. Console, go to Applications > Applications.
  2. Open your WS-federated Office 365 app.
  3. Click the Sign On tab > View Setup Instructions.

    The How to Configure Office 365 WS-Federation page opens.

  4. On the page, go to the If your domain is already federated section.
  5. Copy and run the script from this section in Windows PowerShell.
  6. Run the following PowerShell command to ensure that SupportMFA value is True:

    Connect-MsolService

    Get-DomainFederationSettings -DomainName <yourDomainName>

     

    Example result

     

    ActiveLogOnUri : https://example.okta.com/app/office365/issueruri/ssoAn acronym for single sign-on. In a SSO system, a user logs in once to the system and can access multiple systems without being prompted to sign in for each one. Okta is a cloud-based SSO platform that allows users to enter one name and password to access multiple applications. Users can access all of their web applications, both behind the firewall and in the cloud, with a single sign in. Okta provides a seamless experience across PCs, laptops, tablets, and smartphones./wsfed/active

    DefaultInteractiveAuthenticationMethod :

    FederationBrandName : Okta

    IssuerUri : issueruri

    LogOffUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/signout

    MetadataExchangeUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/mex

    NextSigningCertificate :

    OpenIdConnectDiscoveryEndpoint :

    PassiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/passive

    SigningCertificate : <SigningCertificate>

    SupportsMfa : True

 

If you've chosen to let Okta configure the federation settings for you

In this case, you don't have to configure any settings, you just click Edit and then Save as described below.

  1. From the Okta Admin Console, go to Applications > Applications.
  2. Open your WS-Federated Office 365 app.
  3. Click the Sign On tab > Edit > Save.
  4. Run the following PowerShell command to ensure that SupportMFA value is True:

    Connect-MsolService

    Get-DomainFederationSettings -DomainName <yourDomainName>

     

    Example result

     

    ActiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/active

    DefaultInteractiveAuthenticationMethod :

    FederationBrandName : Okta

    IssuerUri : issueruri

    LogOffUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/signout

    MetadataExchangeUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/mex

    NextSigningCertificate :

    OpenIdConnectDiscoveryEndpoint :

    PassiveLogOnUri : https://example.okta.com/app/office365/issueruri/sso/wsfed/passive

    SigningCertificate : <SigningCertificate>

    SupportsMfa : True

 

Disable this feature

If you decide to turn off this feature, you must manually set the SupportsMFA setting to false for all federated domains that were automatically federated in Okta and had this feature enabled.

Use this PowerShell cmdlet to turn this feature off:

Set-MsolDomainFederationSettings -DomainName <targetDomainName> -SupportsMfa $false

How it works

Okta MFA satisfies Azure AD Conditional Access MFA requirement

If Office 365 is configured with an Azure AD Conditional Access policy that requires MFA, end users trying to access the app are challenged by Okta for MFA to satisfy the Azure AD MFA requirement. Okta then passes the successful MFA claim to Azure AD which accepts the claim and allows access without prompting end users for a separate MFA.

Assuming that Azure AD Conditional Access MFA is enabled and Okta MFA is enabled at the org or app level, or both, Okta passes the MFA claim as described in the following table.

Okta Org-level MFA Okta App-level MFA Azure AD MFA What Happens
Disabled Disabled Enabled

End users will enter an infinite loop. To prevent this, you must configure Okta MFA in order to satisfy the Azure AD MFA requirement.

See the Known issues section above.

Enabled Disabled Enabled End users complete an MFA prompt in Okta. Okta passes the completed MFA claim to Azure AD. The user is allowed to access Office 365. Azure AD accepts the MFA from Okta and does not prompt for a separate MFA.
Disabled Enabled Enabled
Enabled Enabled Enabled

 

Okta enrolls users in Windows Hello for Business

Prerequisite: The device must be Hybrid Azure AD or Azure AD joined.

If your organization requires Windows Hello for Business, end users who are not enrolled in Windows Hello for Business already are prompted to complete a step-up authentication (e.g. SMS, push) in Okta. After successful enrollment in Windows Hello for Business, end users can use it to log in on the device. Okta will help the end users enroll in Windows Hello for Business as described in the following table.

 

Okta Org-level MFA Okta App-level MFA What Happens
Disabled Disabled

End users will enter an infinite loop. To prevent this, you must configure Okta MFA in order to satisfy the Azure AD MFA requirement.

See the Known issues section above.

Enabled Disabled End users complete a step-up MFA prompt in Okta. Upon successful enrollment in Windows Hello for Business, end users can use Windows Hello for Business as a factor to satisfy Azure AD MFA.
Disabled Enabled
Enabled Enabled

 

Related topics

Enhanced provisioning and deprovisioning for Office 365

Integrate Office 365 in Okta

Windows Hello for Business (Microsoft documentation)

Top