Connect with us

Hi, what are you looking for?

Microsoft Identity & Access Management

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.

24 Comments

24 Comments

  1. Marco

    May 13, 2019 at 9:44 AM

    Hi Jason,

    thank you for the excellent guide.

    I would welcome if you could write a tutorial for moving on prem MFA to Azure MFA.

    Thanks for the effort

  2. Gert

    May 27, 2019 at 2:17 PM

    Hi Jason,
    Can the onboard.js be changed so that uses can MFA sign in with john instead of [email protected] Just like the ADFS username password option.
    Thanks

  3. Jason Samuel

    May 29, 2019 at 11:21 AM

    I’m not sure if you can do that Gert since UPN is required for Azure MFA. I have not tried it.

  4. Eli Searle

    July 26, 2019 at 12:57 PM

    Does this require any Azure licensing?

  5. Dmitry

    August 21, 2019 at 6:00 AM

    Hi Jason!
    I did all points in your guide. But when I click on the Azure Multi-Factor Authentication I get an error “An error occurred. Contact your IT department.”
    What I did wrong? How can I troubleshoot it?
    Thanks!

  6. Peter

    October 18, 2019 at 9:46 AM

    Hello Jason,

    I would love to see the write up on how to move from prem MFA to Azure cloud MFA with ADFS.

    Thank you for the great work!

  7. Colin

    October 24, 2019 at 3:53 AM

    Hi Jason. Great article. I’m looking to migrate from on-prem MFA Server to Azure MFA. You mentioned you could provide an article on the steps to doing this. It would be very much appreciated if you could. Thanks. Colin

  8. Jason Samuel

    November 6, 2019 at 11:07 AM

    @Eli, Microsoft announced Azure MFA is free for even Azure AD Free tenants. Latest info is here: https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-mfa-licensing

    @Dmitry, at what step are you seeing that message?

    @Peter @Colin, Thanks guys! I haven’t had a chance to write a guide yet. I have several guides in progress and it is in my backlog.

  9. Steven

    November 27, 2019 at 10:36 AM

    Hi Jason,

    It would be great to see an article on the migration from on-prem to cloud MFA.

    Great article BTW.

    Thanks

  10. Hypex

    December 18, 2019 at 11:04 PM

    Hi Jason,

    Great guide, have you come across a way to use push notification instead of the verification code through AD FS 2016 (with Azure MFA). The code setup works fine, just trying to make it easier for staff when using the Microsoft Authenticator app.

  11. Raj

    December 23, 2019 at 10:33 AM

    Hello Jason,

    A very great article. As this is primarily focused on Web access. How this works with clients like Outlook application. How can we make MFA primary authentication method for clients. Any inputs are highly appreciated.

  12. Jason Samuel

    January 17, 2020 at 8:34 AM

    @Hypex, Thank you, only TOTP is supported at this time. I agree it would be nice to have other methods.
    @Raj, thank you, clients will get a web view during authentication and be able to enter the TOTP.

  13. SlartiMitvar

    February 7, 2020 at 6:46 AM

    Thanks for the very usable article.
    I can now get MFA working very well internally but when I try to use it for an external connection (through WAP) I get SAML validation exception errors.
    I didn’t perform any steps on the WAPs during this config.
    Have I overlooked something?

  14. Slartimitvar

    February 7, 2020 at 10:41 PM

    Please ignore my previous question.
    I eventually determined I had an Azure MFA config issue and all is now OK.
    Cheers

  15. Wan

    February 27, 2020 at 9:05 AM

    Hi, great manual but when pressing the blue ‘Azure Multi-Factor Authentication
    ‘ link it tell me there was an error “Error details: Exception calling SAS.”

    Any suggestions ?

  16. Jesse D Barker

    March 2, 2020 at 5:38 PM

    Do I need to install the certificate on the Web Application Proxy as well? We are currently having some strange issues where Authentication is only working sometimes with MFA. Started a couple weeks ago so just searching for any possible solutions. Seems 50% of the MFA requests work and the other half fail. When I say fail, I mean the server always says it the MFA service didn’t respond.

  17. Jason Samuel

    March 11, 2020 at 12:28 AM

    @Slartimitvar, thanks and glad you got it working.

    @Wan, thanks. What are your Windows logs saying on the AD FS servers when that happens?

    @Jesse, if you are load balancing AD FS, check to see if something has changed there. Usually when something that was working 100% suddenly starts working 50% it’s because of a particular server that may be hung up or telling a load balancer in front of it it’s unhealthy.

  18. Kherwa

    July 8, 2020 at 11:17 AM

    would azure cloud mfa work for ADFS 3.0 Windows Server 2012 r2?

  19. Gilberto Braga

    November 17, 2020 at 6:52 AM

    Thanks Jason, it worked perfectly here. Hugs from Brazil

  20. Mike Courtney

    March 31, 2021 at 6:39 AM

    Hi Jason,

    Another +1 on writing a guide please

  21. SJMiller

    October 7, 2021 at 6:16 PM

    When I run the New-MsolServicePrincipalCredential PS command I get:

    New-MsolServicePrincipalCredential : Service principal was not found.
    At line:1 char:1
    + New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OperationStopped: (:) [New-MsolServicePrincipalCredential], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.ServicePrincipalNotFoundException,Microsoft.Online.Administration.Automation.NewServicePrincipalCredential

    We are using Free Azure AD with AD FS 2019 w/ProxyServer. I I ran Connect-MSOLService and Connect-AzureAD with a globaladmin that also exists in AD on prem.

  22. SJMiller

    October 7, 2021 at 6:19 PM

    Trying to follow along. We have the Free AzureAD with Office365 and it has MFA and Security keys.

    It all works fine until I get to the New-MsolServicePrincipalCredential step:

    PS C:\Windows\system32> New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b-a875-f8b09b8cd720 -Type asymmetric -Usage verify -Value $certBase64
    New-MsolServicePrincipalCredential : Service principal was not found.
    At line:1 char:1
    + New-MsolServicePrincipalCredential -AppPrincipalId 981f26a1-7f43-403b …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OperationStopped: (:) [New-MsolServicePrincipalCredential], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.ServicePrincipalNotFoundException,Microsoft.Online.Administration.Automation.NewServicePrincipalCredential

  23. SJM

    October 8, 2021 at 10:16 AM

    I am fine up to the New-MsolServicePrincipalCredential command. It returns an error “Service Principal was not found”. We are using the Fredd Azure AD that comes with O365 now and we do have Azure MFA that is included with that – we are currently using it for all admin logins. We have no separate Azure AD licenses.
    What would cause this error?

  24. SJM

    October 8, 2021 at 12:39 PM

    Never mind. P1 is included with M365 but not O365. Started Azure P1 Free Trail, assigned the license to the admin doing the install and the command then worked.

Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like

Apache

Today I would like to go over proper URL redirection when using SSL but first I would like to preface this by describing what...

Citrix Workspace

You can use FIDO2 hardware security keys plugged into your physical desktop over the Citrix HDX remoting protocol for use with virtualized Windows Desktop...

Exchange 2003

A useful Exchange 2003 guide I wrote for a friend’s blog originally but I am posting it here on mine now for your viewing...

Apache

In a worst case scenario and all your web servers have failed, what do you do? You could have a standby group of servers...

JasonSamuel.com began in 2008 as a way for me to give back to the IT community. This website features the latest news and how-to's on enterprise mobility, security, virtualization, cloud architecture, and other technologies I work with. This website has evolved over time to become a go-to reference hub for these technologies. It receives hundreds of thousands of unique visitors from all over the world each month. More details on the About Me page.
Copyright © 2008-2023 JasonSamuel.com