Note that this is only applicable for the MFA rules for your Azure AD/Office 365 relying party trust.

In this article I’ll show you the method I like to use to ‘migrate’ from on-premises MFA rules to Azure AD Conditional Access. This doesn’t mean though that you can’t keep using your on-premises ADFS server to perform the MFA, you’re simply letting Azure AD decide when this should be done. Now with Azure AD Conditional Access policies, the definition and logic of when to trigger MFA can, and should, be driven from the Azure AD side given the high level of granularity and varying conditions you can define. In some circumstances, you may have been able to define some level of granularity utilising custom authorisation claims, such as bypassing MFA for ActiveSync and legacy authentication scenarios, but that method was reliant on special client headers or the authentication endpoints that were being used and hence was quite limited in its use. That is, within Office 365 (Exchange Online, Sharepoint Online, Skype for Business Online etc.) or through different Azure AD Apps that may have been added via the app gallery (e.g. The main limitation with this, of course, is the inability to define different MFA behaviours for the various services behind that relying party trust. Prior to conditional MFA policies being possible, when utilising on-premises MFA with Office 365 and/or Azure AD the MFA rules were generally enabled on the ADFS relying party trust itself.

With the recent announcement of General Availability of the Azure AD Conditional Access policies in the Azure Portal, it is a good time to reassess your current MFA policies particularly if you are utilising ADFS with on-premises MFA either via a third-party provider or with something like Azure MFA Server.

Adfs azure mfa