ADFS 2016: MFA

ADFS 2016 changes the way Multi-Factor Authentication (MFA) is  configured and used. With previous versions of ADFS, MFA Server was downloaded and the ADFS adapter installed to provide MFA for users and applications. With Windows Server 2016, the architecture has changed so that ADFS 2016 is integrated with Azure MFA. This means that the IT admin does not need to install any special software or adapter to get MFA working. In addition, MFA now can be used as a primary method of authentication—users don’t need to enter in their password to get access to resources, they can verify their identity using their phone (call, text) or by using the Microsoft Authenticator app.

Before ADFS 2016 MFA can be used, MFA servers need to be registered on your Azure AD tenant: This following needs to be done for each ADFS server in the farm. There is good documentation on how to get this done here: https://technet.microsoft.com/en-us/windows-server-docs/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa

Background

In my lab environment, I installed ADFS 2016 and used the Export and Import scripts available in the Windows Server 2016 media to move over the settings from my 2012 R2 server. The scripts are located in the Support\ADFS folder of the OS media. The biggest key to making this work is to make sure you use the same service account.

FYI:You can easily add ADFS 2016 server into an existing 2012 farm seamlessly but I did not choose to go that route.

Configuration

A certificate needs to be generated on the ADFS server which will be used for authentication against Azure AD.

After a certificate is generated, a new service principal needs to created and the certificate information associated with the service principal. This allows the ADFS servers to authenticate/communicate with the Azure MFA client successfully.

When executing the command to create the service principal ID, you are met with an error saying the end date is an invalid parameter. This seems to be a bug and I was able to get around this by omitting the start and end date altogether.

Now that I have MFA service registered with Azure AD, I can go ahead and enable MFA as an authentication method.  MFA can be used  the primary method of authentication or secondary. Using MFA as a primary method of authentication is great news—this means you don’t have to use your password when logging on to company resources

For my test environment, I’ve setup ADFS with the following configuration:

One of the prerequisites to get Azure MFA to work on-premise is that the “proof-up” or the setup of MFA information needs to happen in Azure AD. This means that multi-factor authentication needs to be enabled for the user. I’ve raised this issue with MS because essentially to use ADFS based Azure MFA you need to turn on Azure AD MFA (more on this later)

Since we’ve enabled both ADFS based Azure MFA and Azure AD MFA, we need a way to prevent double  double MFA prompts (one from Azure and one from ADFS). You will need to change your domain federation settings to the following:

Set-MsolDomainFederationSettings –DomainName domainname.com -SupportsMFA $false

In addition, you will need to pass the MFA claim from ADFS to Azure AD so it will understand that you have already successfully authenticated via MFA on-premises. This should be added to the Office 365 Relying Party Trust (which is service I’m testing against)

(=> issue(Type = “http://schemas.microsoft.com/claims/authnmethodsreferences“, Value = “http://schemas.microsoft.com/claims/multipleauthn“);)

**After raising the proof-up question with MS they recommended to use the following for these scenarios:

1) Authenticating to Internal Applications – Internal applications will be able to leverage ADFS based Azure MFA for authentication. This assumes that the user has setup alternate authentication methods in Azure AD. You can send the user the link to set up MFA methods or if they use Office 365 or Microsoft cloud services, they will be forced to go through this setup.

2) Authenticating to Azure AD Applications – For Azure AD applications, Azure AD MFA will provide authentication. This is of course assuming Azure MFA is turned on for the user.

From testing, I was able to use ADFS based MFA for both scenarios and get it to work.  It worked because I went through the initial proof-up setup (Turning on MFA in Azure AD or Setting up alternate authentication methods by going to myapps.microsoft.com)

User Experience

When a user logs in for the first time to Office 365, they will be met with a prompt to setup MFA (I’ve set the SupportsMFA parameter to false and enabled MFA for the user in Azure AD)

.

I configured MFA for  my test account to use mobile app notifications. Once you click on “Set up” you will receive a QR code which you can scan using the Microsoft Authenticator app (Work Account). Now when I login to Office 365, I’m redirected to my ADFS server and you will notice an option at the bottom for MFA Authentication:

Once you click on Azure Multi-Factor Authentication, you will have to then use the verification code from the Microsoft Authenticator app to authenticate yourself to Office 365.

Recommendations/Thoughts:

1. MFA as a primary method of authentication helps prevent the use of passwords thereby reducing the chance that the password gets stolen & it improves the experience of users that are trying to login with mobile devices where there’s not much real estate on the keyboard to type in a complex password.
2. I suspect more documentation on this topic will be published before Windows Server 2016 is available to corporate customers which might explain some of the caveats I’ve run into.
3. The integration of the cloud services such as the MFA service with the Server OS is a great way to unify the setup and configuration process regardless of if you are hybrid or cloud organization.