This article provides answers to frequently asked questions about mandatory MFA requirements for Microsoft applications.
Table of Contents
What change is happening?
How does this change impact Okta's integration with Microsoft?
What is Okta doing to mitigate this change?
Do I have to take any actions to leverage these upgraded integrations?
How long do I have to make these changes?
I have O365 admins who want to SSO using Okta. With Microsoft mandating MFA for these users, how does Okta support this scenario?
Can I enforce MFA only on users who are Microsoft administrators and federated by Okta?
Can I leverage Azure Conditional Access Policies instead of Okta’s App Assurance policies for Office 365 to enforce MFA only on certain applications inside of Office 365?
I have an Azure Conditional Access Policy that only requires MFA for certain Office 365 applications for my end users, but I do not have any MFA policy for Office 365 on Okta. How can I make this work with Okta?
Can I customize the Azure Conditional Access policy to require specific authenticators when trying to sign in to certain applications in Office 365?
I have not rolled out MFA for Okta’s Office 365 App yet. Will I be affected by MSFT’s enforcement on October 15?
I am not ready to implement this change. Can I request an extension?
Can I enable MFA for the Azure administrator account configured for SSO or Provisioning with Office 365 with Okta?
We have an Office 365 app that uses Manual with PowerShell configuration. What should I do?
What is the expected downtime for both of these changes?
Microsoft will allow third-party MFA providers to integrate with Azure AD via Microsoft’s External Authentication
Why are we still seeing Azure Active Directory PowerShell in auth logs?
What change is happening?
Microsoft will require Multi-Factor Authentication for any administrators signing into the Azure Ecosystem. This change will happen in two phases:
-
Phase 1: Starting Oct 15, enforcement for MFA at sign-in for Azure portal only will roll out gradually to all tenants. This phase will not impact any other Azure clients, such as Azure CLI, Azure PowerShell, and IaC tools.
-
Phase 2: Starting mid 2025, enforcement for MFA at sign-in for Azure Command Line Interface (CLI), Azure PowerShell, and Infrastructure as Code (IaC) tools will gradually roll out to all tenants.
How does this change impact Okta’s integration with Microsoft?
Okta has historically required an Azure administrator account for setting up Single Sign-On (WSFed Auto) and Provisioning integration, which allows customers to manage users, their roles, and licenses. While we anticipate no impact in Phase 1, we anticipate that Single Sign-on and Provisioning integrations will be affected when Microsoft starts its Phase 2 enforcement in early 2025.
What is Okta doing to mitigate this change?
Beginning September 17, 2024, for Single Sign-On and September 24, 2024, for Provisioning, Okta will eliminate the need for an Azure administrator account and introduce a modern and secure OAuth-based flow leveraging the Microsoft Graph framework. We strongly recommend that customers leverage this upgraded integration, as it is more secure and will ensure that the MFA enforcement for Azure does not affect customers.
Do I have to take any actions to leverage these upgraded integrations?
Yes. Okta Administrators must change the Office 365 app in Okta to leverage the upgraded integration.
-
For Single Sign-on (WS-Fed Auto): For any customer who has an Office 365 app in Okta configured with WS-Fed Auto configuration, please follow this step-by-step guide
-
For Provisioning: For any customer who has configured Provisioning for Office 365 (includes Profile Sync, License & Role Management, User Sync, and Universal Sync), please follow this step-by-step guide.
How long do I have to make these changes?
Microsoft has indicated that it will start enforcing MFA for Azure Powershell, Azure CLI, and Infrastructure as Code (IaC) by Early 2025. However, Microsoft has not specified a definitive date. To be proactive and secure our customers, Okta requires that all customers provide consent and leverage the upgraded integrations by December 31, 2024.
I have O365 admins who want to SSO using Okta. With Microsoft mandating MFA for these users, how does Okta support this scenario?
At this point, Microsoft is only mandating MFA for logging into the admin centers such as Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center. They’re not mandating MFA to log into other Microsoft apps. If users try to log into admin centers, they must perform MFA. Okta currently supports the “Use Okta MFA for Azure AD” feature, which allows you to use Okta MFA to satisfy Microsoft’s MFA requirements. Please follow this documentation to enable it. Okta strongly recommends enabling MFA for all users, not just administrator users alone.
Can I enforce MFA only on users who are Microsoft administrators and federated by Okta?
Yes, customers can create groups that target only administrators and enable MFA for them. However, Okta strongly recommends enabling MFA for all users.
Can I leverage Azure Conditional Access Policies instead of Okta’s App Assurance policies for Office 365 to enforce MFA only on certain applications inside of Office 365?
Yes, Okta will be able to satisfy Azure’s MFA requirements for Admins when trying to sign into the Azure admin centers such as the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center, even if Okta’s App Assurance policies does not have MFA required when signing into Office 365. Additionally, Okta can support the scenario where customers can configure Azure Conditional Access Policies to require MFA when logging into specific Azure services such as Intune, providing a seamless way to leverage Okta’s MFA solution to access Azure’s MFA services.
I have an Azure Conditional Access Policy that only requires MFA for certain Office 365 applications for my end users, but I do not have any MFA policy for Office 365 on Okta. How can I make this work with Okta?
Okta already supports sending MFA claims to Azure with the “Use Okta MFA for Azure AD” feature. However, starting September 24, 2024, customers can leverage Azure Conditional Access Policies to only require MFA for certain Office 365 applications, and dynamically prompt for Okta MFA when needed, without having MFA on Okta’s App Assurance policy. To achieve this, customers must also enable the Step-up authentication for Office 365 feature, which will be available in Self-Service EA. This feature can be enabled by going to Settings → Features → {Step-up Authentication for Office 365}.
Note: This feature is only available for OIE orgs and not in classic.
Can I customize the Azure Conditional Access policy to require specific authenticators when trying to sign in to certain applications in Office 365?
Okta does not currently support satisfying specific MFA factors that the Azure Conditional Access Policy requires. This is planned on our roadmap.
I have not rolled out MFA for Okta’s Office 365 App yet. Will I be affected by MSFT’s enforcement on October 15?
No, you will not be affected. If the administrators are enrolled with Okta MFA by October 15, Office 365 admins trying to sign into Azure admin centers such as the Azure portal, Microsoft Entra admin center, and Microsoft Intune admin center will be prompted for MFA even though Okta’s App Assurance for Office 365 policy does not require MFA.
I am not ready to implement this change. Can I request an extension?
Microsoft specifies that you can request a postponement using this link. However, at this point, Okta does not plan on offering any extensions and requires customers to leverage the upgraded integrations by December 31, 2024.
Can I enable MFA for the Azure administrator account configured for SSO or Provisioning with Office 365 with Okta?
We strongly recommend leveraging the updated integrations to remove the administrator account from the SSO and Provisioning integration before you enforce MFA for these admin users when trying to log in to the Azure portal.
We have an Office 365 app that uses Manual with PowerShell configuration. What should I do?
We offered guidance earlier this year for customers who leverage MSOL Cmdlets (Connect-MSOlService) to federate manually. Please follow this article on migrating the same to MS Graph. No action is needed now for customers with WSFed apps on the new MS Graph Cmdlets (Connect-MgGraph).
What is the expected downtime for both of these changes?
We do not anticipate any downtime when providing consent to leverage this upgraded integration. However, Okta strongly recommends that our customers perform this change during non-business hours, like weekends, to reduce the impact.
Microsoft will allow third-party MFA providers to integrate with Azure AD via Microsoft’s External Authentication Methods (EAM). Does EAM have anything to do with this change?
No. EAM is only for organizations that are NOT federated with Okta for Single Sign-On. EAM is not required in the context of removing administrator accounts for SSO and Provisioning.
Why are we will still seeing Azure Active Directory PowerShell in auth logs?
Okta does not use PowerShell endpoint to connect to AAD. Okta uses the latest MS Graph endpoint, but the client-appId sent in the request is for PowerShell. That is why the Audit log it shows as “Azure AD Powershell".
This is a cosmetic change and does not impact any functionality, and auth requests will continue to work.
