Few months back I wrote an article about utilizing claims rules to enable scenarios such as “force additional authentication for requests coming outside of the corporate network”. More specifically, I examined how AD FS can be configured to use any additional 2FA provider and combine this with the claims rule engine to configure the authentication rules for any ADAL-enabled client (i.e. the ones that support Modern authentication). The list of conditions to use included the location of the client, device status (i.e. registered, managed or unknown device), group membership and any other AD attribute for the user, and to some extent the application used. You can find the original article here: http://blog.enowsoftware.com/solutions-engine/ad-fs-claims-rules-and-modern-authentication.
At the time the article was published, using federated scenario and configuring the AD FS claims rules was the only option available to configure such conditional access scenarios for Office 365 apps. While the Azure MFA service has long offered the whitelisting feature, which allows us to control access based on the location of the client, it lacked the granularity AD FS claims rules offered. Now, with the introduction of MFA conditional access for Office 365 applications, things have changed and in some regards the service is even superior to AD FS. Let’s take a quick look.
First, just to clarify that conditional access in Azure AD isn’t something new, it has been around for a while now. What’s new is the fact that it now works for Office 365 workloads as well. The feature can be enabled on per-directory and per-app basis: login to your Azure portal, select the Office 365 directory you want to work with, then click on the Applications tab. You would see several Office 365 related applications listed there, currently only the Office 365 Exchange Online, Office 365 SharePoint Online, Dynamics CRM and Yammer one support conditional access. Once you select the application, click on the Configure tab and press the ON button next to Enable access rules. You will then be able to select to which users the settings will apply and what the actual access rule will be: require MFA, require MFA only for external access or block external access altogether. Detailed instructions with screenshots can be found for example this TechNet article.
A small note must be made at this point – you need to have Azure AD Premium enabled for the directory in question (trial is fine) for the Configure tab to appear when selecting the Office 365 applications. If you have just activated it, you might have to refresh the browser window.
Let’s talk about the user experience now. The actual MFA process will be pretty much the same, the difference here is how it’s triggered. If you have enabled/enforced the user for MFA (globally), the user will still see the MFA prompt after logging in to any Office 365 resource, including the portal page. After a successful MFA, the user will be granted the relevant token and can use said token to gain access to any of the services, including ones for which you might have configured conditional access rules. In other words, the user will not have to perform MFA a second time. If you are not requiring MFA globally for the user, he will be able to login with just a username and password to the portal and any resource not in the scope of the conditional access rule. Trying to access a protected resource however, for example clicking the Mail icon in the App launcher, will take him to the Azure AD login page where he will have to perform the MFA.
In case you have selected to block access instead of requiring MFA, the user will be informed via the following error message:
Now, the people that have paid attention to the article I referenced in the beginning are probably well aware that ADAL-enabled clients always communicate on the passive endpoint. In turn this can cause problems with distinguishing Exchange requests from SharePoint ones and so on, as not all applications will send enough information for us to prepare a proper claims rule. In the case of MFA conditional access, this is all taken care of by Microsoft (or more specifically EvoSTS). The login attempt is always performed against the service which is well aware of the workload you are trying to access, thus it can make the difference between Exchange or SharePoint or any other service and ask for MFA only when needed. Which in turn is a great advantage compared to AD FS, where you have to spend a lot of time trying to accommodate claims rules to do the work.
Another difference compared to AD FS if the fact that you can only have a single rule for conditional access, per application. You cannot have a group of users being blocked when trying to access SharePoint externally, while at the same time force another group to always perform MFA, and so on. When it comes to the number of rules and their customizability AD FS still has some advantages. Device-related conditions (registered, managed, unknown device) are also missing at the moment, but they should be coming soon.
One last remark – while this new feature makes Azure MFA far more usable and (almost) makes it a viable replacement for AD FS, it’s not a magic bean. You will still be plagued by some of the not-so-good changes Modern authentication brought. For example, switching the network after you have already successfully logged in to the application allows you to continue accessing the service for an extended period of time, as we still lack a method of revoking tokens (no, Intune conditional access is not a solution, just like app passwords never were).
Here’s another useful resource, the Conditional access FAQ: https://azure.microsoft.com/en-us/documentation/articles/active-directory-conditional-faqs/