How to use Microsoft AD FS with Azure MFA as Primary Authentication to protect user passwords or take your company completely password-less

I wrote about setting up password-less phone sign-in authentication with Microsoft Authenticator and Azure AD recently which is a great option in Public Preview right now that everyone should be testing. Many of the companies I work with use Azure AD Connect to federate Azure AD with AD FS for Office 365 and other SaaS apps so I thought I would write a quick guide on how to setup Azure MFA as Primary Authentication. This is the first step to not only protect your users existing vulnerable and commonly attacked passwords but to also take your company into the password-less era.

Why you should configure your AD FS environment like this

There are two reasons why you would want to re-configure your AD FS deployment this way to help protect your company versus the traditional AD FS + Azure MFA as second factor deployment.

1. To protect your users from password based attacks. Usually, we enter our user ID and password as the 1st factor before getting a multi-factor authentication option from Azure MFA (cloud) or Azure MFA Server (on-prem) as the 2nd factor. This exposes a big risk to many companies because anyone can sit there and perform a brute force attack on your user account passwords. By setting Azure MFA as primary authentication instead of secondary authentication, you force your users to use Azure MFA first BEFORE they enter their password or other factors (depending on AD FS version you have). This pretty much makes your company immune to password-based attacks and attack triggered password lockouts since attackers will never even see a password prompt. They won’t be able to get past the first MFA screen.
2. To take your company password-less. By using Azure MFA as primary authentication, you can chain/factor sequence it with another authentication method that is not a password for a completely password-less experience for your users. This makes your company immune to password attacks you constantly hear about in the news and in my opinion where all companies should be looking at moving to.  I firmly believe the future of password-less authentication for enterprises will be things like Microsoft Authenticator, Windows Hello for Business, and FIDO2 CTAP2/WebAuthn compatible keys like the YubiKey 5.

A non-exhaustive list of active and passive password attacks this configuration can help protect your organization from:

• Phishing attacks against your users for their passwords
• Social engineering attacks against your users to divulge their passwords
• Malware, trojans, spyware, or keyloggers to capture and send the user’s password to the attacker for later use
• Dictionary password attacks
• Brute force password attacks
• Password Spray attacks (aka a reverse brute force attack that uses common passwords against a list of user accounts to circumvent password lockouts and rate limiting)
• Rainbow table password hash cracking attacks
• Offline cracking of a password dump from one of your vulnerable systems
• Password replay attacks
• Packet capture or MITM (man-in-the-middle) attacks using the network the user is connected to itself to capture passwords
• Someone spotting your user has a bumper sticker on their car saying something about STAR WARS and then guessing their password is “DarthVader123”
• Stolen credentials that just happened to show up on a dark web marketplace for sale.  Or simply dumped on Pastebin or public forums for fun

The attacker can obtain a user’s password in any of those attack vectors but it remains useless since they have no opportunity to actually enter that password anywhere!

Pre-requisites

In order to setup Azure MFA as Primary Authentication with AD FS, this does require you to move to Azure MFA (cloud-based version). I have not deployed Azure Multi-Factor Authentication Server (on-prem/hybrid version) in a few years for anyone as pretty much everyone I work with has moved on to cloud-based Azure MFA. Feature parity is pretty close to the same at this point and in my opinion, the days of Azure MFA Server on-prem are numbered. If you’re still on the on-prem Azure MFA Server, it is very easy to migrate to the cloud-based Azure MFA. I have moved several companies over the last few years and if anyone needs a guide just let me know and I can write one.

I’m going to assume you have a working AD FS environment already that is federated with Azure AD using Azure AD Connect:

And you can check your Azure AD tenant under Azure Active Directory > Azure AD Connect to verify Federation is enabled:

And you can futher drill down to see exactly which domains are Federated:

In my configuration example in the next steps, I am using AD FS 4.0 (aka AD FS 2016) but you can do the same with AD FS 5.0 (AD FS 2019). AD FS 2019 is still rather new for many enterprises so I chose to write this guide for AD FS 2016 just so a wider audience of enterprises can make this change comfortably with this guide.

How to configure AD FS and Azure MFA to work like this

1. Log into your AD FS server. In my example, I am using AD FS 4.0 with a Farm Behavior Level (FBL) set to 3 which means Windows Server 2016 and an Active Directory 2016 schema. You can always run the PowerShell cmdlet “Get-AdfsFarmInformation” on your AD FS server to show your FBL version. Go ahead and open the AD FS console:

2. Click AD FS > Service > Authentication Methods > Edit Primary Authentication Methods

3. You’ll notice for primary authentication there is currently no option for Azure MFA. There will be a notice asking you to integrate with an Azure AD tenant in order to use Azure MFA. Again, remember this is not the Azure MFA Server from on-prem which is usually configured on the Multi-factor tab. This is the cloud-based Azure MFA which means AD FS needs to talk directly to your Azure tenant and Azure AD to invoke Azure MFA:

4. Log into your Azure tenant and copy out your Tenant ID.

5. On your AD FS server, open up an Administrator PowerShell window and type the below command to generate a tenant certificate to use with Azure MFA:

6. This cert needs to be generated in each AD FS server in your farm. You can open up the Certificates console and see it is stored under Local Computer > Personal > Certificates as a Client Authentication certificate. Note that the default expiration date is 2 years from the date you generate it so be mindful that you need to renew this and include it in your AD FS certificate maintenance plans.

7. Now you need to enable the AD FS servers to communicate with the Azure Multi-Factor Auth Client already registered in your Azure AD. The cert you just generated will be used as credentials to the Service Principal for the Azure Multi-Factor Auth Client. In your Administrator PowerShell window, type:

and accept all the prompts to get the Azure AD module installed from the PSGallery.

8. Then type:

and accept the prompt to get the Microsoft Online Services module installed.

9. Now type:

and a web view will open up asking you to sign-in to Azure. I typically use a global admin account here:

10. Once authenticated, we need to set the Service Principal to use the new cert with Azure MFA. Type in:

The App Principal ID in this step of “981f26a1-7f43-403b-a875-f8b09b8cd720” is for the Azure Multi-Factor Auth Client is not something unique you need to change. Leave it as-is and don’t modify this GUID. Type the line exactly as I have it above. Make sure to do it on all your AD FS servers.

11. Now the next step is where we tell AD FS to use your Azure AD tenant with Azure MFA. You only need to run this from one of your AD FS servers since all servers will see this config change:

12. Now go into Services on each of your AD FS servers and restart the “Active Directory Federation Services” service.

13. Close any AD FS MMC consoles you have open and then re-open and go to Edit Authentication Methods again. Now you will see a new Primary authentication option of Azure MFA for use with both your Extranet and Intranet!

14. Go ahead and check the box next to them so you can choose when the Azure MFA option is shown to users. Most companies I work with choose to only enable it for their Extranet, meaning users that come in through the AD FS WAP (Web Application Proxy) servers in the DMZ. I’m just going to select both in this example since I will be testing logins from an internal Windows 10 desktop in the next few steps and I want to see the Azure MFA option show up:

The AD FS with Azure MFA as Primary Authentication user experience

15. Now on my Windows 10 desktop, I am going to navigate to the IdP initiated AD FS login URL to test this. You’ll also probably want to disable Windows Authentication (IWA aka Integrated Windows Authentication) on the Intranet in AD FS if this a test environment just so you don’t get auto-logged in. Go to:

Hit the “Sign in to this site” radio button and then click Sign in.

16. You will then see all your configured authentication options and the new “Azure Multi-Factor Authentication” option. In this screenshot you are seeing Forms Authentication, Certificate Authentication (aka X.509 certificate authentication), and Azure MFA as Primary Authentication all side by side:

When AD FS is configured for those 3 options like this:

17. In an Extranet zone to achieve what we are wanting to do where user passwords are not part of primary authentication, we can do something like this. In this example, I have removed Forms Authentication (meaning the user ID and password option) and now only the Certificate Authentication and Azure MFA as Primary Authentication options remain:

And AD FS is configured for just those 2 options like this:

And when the user clicks on the blue “Azure Multi-Factor Authentication” link they will see this as well as an option for “Sign in with other options”.  Clicking on that will just take them back to the preceding screen of options.

18. Most companies opt to just enable Azure MFA only when they want to move to this configuration for their Extranet. Again, I am testing against Intranet for the purposes of this guide since I am internal but your Extranet setting would look like this. This way the user doesn’t even have to select the blue “Azure Multi-Factor Authentication” link. Since their only sign-in choice is this option, they will immediately be presented with the login screen for Azure MFA in this configuration:

19. The actual Azure MFA login screen is a thing of beauty. Completely immune to password attacks since this is the only surface exposed to the world! Notice how the user only needs to enter their Username and their TOTP (time-based one-time password) verification code from the Microsoft Authenticator app in order to sign-in. The blue “Sign in with other options” is gone in this scenario this Azure MFA is the only Primary authentication method allowed:

The attacker can never get past this screen since they don’t have access to the user’s Microsoft Authenticator app on their phone with the TOTP code that is changing every 30 seconds. Unlike a static password, this is a moving target they’ll never be able to guess or crack!

Onboarding your users so they can use this Azure MFA as Primary Authentication option

Users need to be enrolled in Azure MFA and use Microsoft Authenticator on their phone in order for this solution to work. They need to navigate out to:

https://aka.ms/mfasetup

And register their phone for use with Azure MFA through a “proof up” process. I’ve covered this in depth over the years already if you’ve followed some of my previous Azure MFA guides.

If you are using Azure AD for authentication, you can force users to enroll in Azure MFA and scan the Microsoft Authenticator QR code as part of the authentication flow. Since AD FS is code that exists on your servers, there is no “proof up” option by default. But the good news is you can create your own onboarding experience to get users to proof up by redirecting them to the Azure MFA proof up enrollment page. You just modify the “onload.js” Javascript file on your AD FS server to capture and redirect when the user is detected to not be registered with Azure MFA. This works well with IdP initiated sign-ins but I have not been able to get it working for SP initiated sign-ins on AD FS 2016.

I also want to point out that if you are using Azure MFA as the only Extranet option on AD FS, users will not be able to proof up when they are working offsite. What I see some companies do is enable AD FS to use Windows Authentication (IWA) internally so users can only enroll in Azure MFA when they are on the company network. This is often not a great scenario for external users that don’t come onsite or external vendors since they will have no way to proof up without being on the company network. VPN or virtual desktops are often an option for these folks to hit Intranet authentication but if AD FS is protecting those externally, then again it’s a “chicken or egg” scenario where they can’t proof up to log into those remote access systems.

I also want to point out that using Azure MFA TOTP alone without chaining/factor sequencing with Azure AD Conditional Access that triggers 2nd factor Azure MFA, a certificate, YubiKey, smartcard, other external MFA providers, etc may be considered a single factor. Yes, the word “MFA” is in there on the page but that’s used as the name of the Azure MFA service itself in this context, not that it means you are using multi-factor authentication as in 2 or more factors of authentication.  However, a TOTP that changes every 30 seconds is significantly more secure than a static user password that gets changed every 42 days (default for Active Directory unless you change it).  Some companies extended the maximum password age out to 60 or even 90 days which is the absolute max to meet certain compliance requirements.  That’s a long time for a compromised credential to float around in the wild.

A new feature in AD FS 2019 is the ability to use other external MFA providers as primary authentication. So you can choose let’s say a hardware security key such as the YubiKey 5 NFC for the 1st factor, then use Azure MFA TOTP as the second factor as additional authentication.  When you go to Authentication Methods in AD FS 2019 you will see Primary and Additional tabs instead of Primary and Multi-factor as in AD FS 2016.  This is to denote that authentication using what may traditionally have been considered the 2nd factor can now easily be interchanged with the traditional 1st factor (i.e. user password).

One thing I would like to see in the future for companies that don’t want to do factor sequencing/chaining with an external authentication provider is the ability to enforce App Lock on Microsoft Authenticator itself. The ability to use App Lock is available on both iOS and Android versions of Microsoft Authenticator:

This means that every time the user opens Microsoft Authenticator, it requires a biometric or passcode to help prove their identity which satisfies the 1st factor of “something you are” or “something you know”:

You cannot currently enforce that users must enable this Authenticator App Lock option as part of Azure MFA proof up or the Device Registration feature required for phone-sign with Authenticator. I hope to see this feature added to Azure MFA registration/proof up in the future because that would mean you could have 2 factors (biometric or device passcode which is something you are or know) plus TOTP in Authenticator (which is something you have) without the need for having to configure anything extra in AD FS.

Hope this guide has helped and please leave any questions or comments below.