AD FS 2016 and Azure MFA - a few Nuances

I was recently helping a colleague with AD FS 2016 and Azure MFA integration, specifically in-line proof up of users. Working through this, there were a few points of confusion that we were able to clear up and I wanted to share these here

Background

Before I go any further, there are a few things I want to lay out that will be important later. Refer to the following

This diagram is somewhat simplified but captures the key aspects that are important to this discussion -

1. Cloud applications and services have a relying-party trust with Azure Active Directory (Azure AD). This includes Azure subscriptions (the administration portal), Office 365 (O365) and other SaaS applications

2. When your Azure AD tenant is federated with on-premises AD FS, there is a relying-party trust (RPT) between your tenant and your AD FS farm. This relying-party trust is named "Microsoft Office 365 Identity Platform". This is sometimes confusing for folks because they think it means O365. It doesn't, it means that the Azure AD tenant trusts the authentication mechanisms of the AD FS farm. Furthermore, any authentication requirement that you apply to the "Microsoft Office 365 Identity Platform" RPT will be enforced for all applications and services that have an RPT with Azure AD (you authenticate against AD FS before you pass back via Azure AD to the application)

3. You may (or may not) have other claims-aware applications that have a relying-party trust directly with AD FS. Typically, these would be hosted on-premises or may be third-party applications that are not integrated with Azure AD

Using Azure MFA

Referring to the diagram, there are two places where Azure MFA may be enforced -

1. At Azure AD - preferably using Conditional Access (CA) Policy which you can read more about here - https://aka.ms/ConditionalAccessDeploymentPlan. CA allows you to configure different requirements for different applications and users. Requiring MFA is one of them. Taking this approach provides the most granular control

2. At AD FS. Taking this approach offers some granular control but generally speaking, you want to avoid using MFA against the "Microsoft Office 365 Identity Platform" RPT because enforcing it here, enforces it for all applications and services that are relying-parties to Azure AD. The real purpose of integrating Azure MFA with AD FS is to provide stronger authentication for your other AD FS relying-parties. To configure AD FS 2016 with Azure MFA, refer to /en-us/windows-server/identity/ad-fs/operations/configure-ad-fs-and-azure-mfa

For more guidance deploying Azure MFA, refer to the deployment plan here - https://aka.ms/MFADeploymentPlan

Azure MFA Proof Up

I'm finally ready to discuss the core point of this post.

When Azure MFA is enforced in the Azure AD tenant, either directly or via a Conditional Access Policy, users who have not yet signed up for Azure MFA (chosen their authentication options and provided their mobile phone number) are directed to https://account.activedirectory.windowsazure.com/Proofup.aspx where they can set this up. This is a requirement at the first sign-in whether CA or direct assignment (which is no longer recommended) is used.

When Azure MFA is enforced against an AD FS relying-party, this redirect does not take place automatically. The following customization needs to be made (I assume here that your AD FS deployment is using the Default ADFS Web Theme)

1. Open a PowerShell prompt on your Primary AD FS server and create a new AD FS Web Theme by executing
New-AdfsWebTheme –Name ProofUp –SourceName default
2. Export the default AD FS Web Theme by executing
Export-AdfsWebTheme –Name default –DirectoryPath c:\theme
3. Open the C:\Theme\script\onload.js file in a text editor
4. Append the following code to the end of the onload.js file

 //Custom Code
//Customize MFA exception
//Begin

var domain_hint = "<YOUR_DOMAIN_NAME_HERE>";
var mfaSecondFactorErr = "The selected authentication method is not available for";
var mfaProofupMessage = "You will be automatically redirected in 5 seconds to set up your account for additional security verification. Once you have completed the setup, please return to the application you are attempting to access.<br><br>If you are not redirected automatically, please click <a href='{0}'>here</a>."
var authArea = document.getElementById("authArea");
if (authArea) {
    var errorMessage = document.getElementById("errorMessage");
    if (errorMessage.innerHTML.indexOf(mfaSecondFactorErr) >= 0) {

    //Hide the error message
        var openingMessage = document.getElementById("openingMessage");
        if (openingMessage) {
            openingMessage.style.display = 'none'
        }
        var errorDetailsLink = document.getElementById("errorDetailsLink");
        if (errorDetailsLink) {
            errorDetailsLink.style.display = 'none'
        }

        //Provide a message and redirect to Azure AD MFA Registration Url
        var mfaRegisterUrl = "https://account.activedirectory.windowsazure.com/proofup.aspx?proofup=1&whr=" + domain_hint;
        errorMessage.innerHTML = "<br>" + mfaProofupMessage.replace("{0}", mfaRegisterUrl);
        window.setTimeout(function () { window.location.href = mfaRegisterUrl; }, 5000);
    }
}

//End Customize MFA Exception
//End Custom Code

Note that you need to change "<YOUR_DOMAIN_NAME_HERE>"; to use your domain name. For example

var domain_hint = "contoso.com";

5. Save the onload.js file
6. Import the onload.js file into your custom theme by executing the following at the PowerShell prompt
Set-AdfsWebTheme -TargetName ProofUp -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="c:\theme\script\onload.js"}
7. Apply the custom AD FS Web Theme by executing
Set-AdfsWebConfig -ActiveThemeName

Following these steps, users who are required to use Azure MFA against an AD FS relying-party but who have not registered for Azure MFA will be redirected to the proof up page -

Redirect -

Proof Up -

IMPORTANT: If you have gone against the recommendation I made earlier - to avoid MFA on the "Microsoft Office 365 Identity Platform" relying-party trust, users will not be able to access the proof up page. This is because the proof up page is a relying-party to Azure AD and by requiring MFA on the "Microsoft Office 365 Identity Platform" relying-party trust, you create a chicken-and-egg scenario

Comments

• Anonymous
  June 20, 2018
  When editing the onload.js file the initial re-direction works, but then after its completed and the user re-signs in, it keeps wanting to re-direct and gets stuck in a loop. Any ideas on why it would get stuck at the landing page and try to re-direct for the user to keep setting up the 2FA
  • Anonymous
    June 20, 2018
    I'm not sure I see the same thing. After my user chooses a phone option (text/call) and verifies, I land on the MFA page where I can choose other options (authenticator app). As I stated in the custom error message that you see before the redirect, the user has to navigate back to the app after proof up themselves.This is just a simple example. I'm not a .js guy really. There may be more complex handling you can do but given the lack of sample code out there, I thought this basic example was a start ...
• Anonymous
  June 20, 2018
  also http://aka.ms/conditionalaccessplan just re-directs to https://www.microsoft.com/en-au/
  • Anonymous
    June 20, 2018
    Fixed now.