HOWTO: Enable Azure Multi-factor Authentication on AD FS

Hybrid Identity

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll add an additional layer of information security to authentications that are routed through the Active Directory Federation Services (AD FS) implementation.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).

 

Why look at Multi-Factor Authentication

Many organizations rely on usernames and corresponding passwords to verify the person authenticating. However, there are several reasons why this is not a sufficient method to securing authentication:

  1. Web-based applications typically use the email address as the user name, because this is a globally unique identifier that people can get cheaply. Microsoft recommends keeping the userPrincipalName attribute equal to the mail attribute.
  2. People reuse passwords between accounts.
  3. Accounts are breached at a rate of 2 services per day.
  4. People are bad at coming up with strong passwords.

A (temporary) solution is to add multi-factor authentication to the authentication flow. This way, after a person has correctly entered the username and password, a second verification is performed. This verification is based on information that was previously registered, and should leverage a different authentication factor:

  • Something you can prove you know
    The password most organizations use
  • Something you can prove you are
    Think of a fingerprint, face or iris scan, like Apple has with TouchID and FaceID, and Microsoft offers on its Surface devices.
  • Something you can prove you have
    Think of a token device, a FIDO 2.0 key, certificate tied to a TPM chip or access to a phone or phone number in the form of returning a one-time password that you receive through a text message, a phone call or an authenticator app,

When you combine multiple authentication factors, multi-factor authentication (MFA) emerges, allowing for more secure authentication.

Reasons why

Usually, it only takes one leaked password to get to sensitive information an organization harbors. This could be privacy-related information related to employees and customers, but could also be information regarding products (source code), intellectual property and patents.

For systems, services and applications containing these types of information, multi-factor authentication should be used. For Azure AD-integrated applications, Conditional Access and Identity Protection offer multi-factor authentication, when needed. For AD FS-integrated applications, applying multi-factor authentication is more straightforward, unless you want to dig deep into REGEX…

Possible negative impact (What could go wrong?)

Multi-factor Authentication is a burden to end-users. Your colleagues and customers might not understand how to effectively perform multi-factor authentication, or move to a competitor that doesn’t require multi-factor authentication, or only when needed.

Choosing the right authentication method is important. Some multi-factor authentication methods are not as secure and user-friendly as others. For instance, because of recent SIM-swapping attacks, MFA through text messages is deemed too insecure to serve a purpose as multi-factor authentication method. Text messages are also inadequate for the situation where a person is on a plane, does have WiFi, but doesn’t have cellular reception.

 

About the Azure MFA Adapter

Microsoft introduced the Azure MFA Adapter in Windows Server 2016. When the AD FS farm runs the Windows Server 2016 Farm Behavioral Level (FBL), or up, this built-in adapter can be enabled and used.

When used, the Azure MFA Adapter communicates to Microsoft’s Azure MFA service to perform multi-factor authentication. People register only once for Self-service Password Reset, multi-factor authentication for Conditional Access, multi-factor authentication for Identity Protection and for multi-factor authentication for systems, services and applications through Active Directory Federation Services (AD FS).

Note:
Azure MFA Server also offers an AD FS MFA Adapter, but Microsoft recommends not performing new implementations of Azure MFA Server.

 

Getting ready

To implement the Azure MFA Adapter and secure AD FS-integrated systems, services and applications with multi-factor authentication, make sure to meet the following requirements:

Roll-out requirements

First off, everyone in scope for the AD FS-integrated systems, services and applications with multi-factor authentication needs to have performed their Azure MFA registration.

If a person doesn’t have an Azure MFA registration, access to the AD FS-integrated systems, services and applications for which multi-factor authentication is required, will be denied.

The scripts to get to know the colleagues using Azure Multi-Factor Authentication still offer sufficient functionality to discover who has an Azure MFA registration and which authentication method they use.

Information Requirements

To avoid multi-factor authentication prompt fatigue, multi-factor authentication should ideally only be required when strictly needed. It’s not the most brilliant of ideas to require multi-factor authentication for all AD FS-integrated systems, services and applications. Determine the systems, services and applications that truly need it, and require MFA in the situations where you need it. Application owners typically know best what their application does and needs.

System requirements

Make sure the AD FS servers run Windows Server 2016, or above, and are installed with the latest cumulative Windows Updates. Make sure the AD FS farm runs the Windows Server 2016 Farm Behavioral Level (FBL), or above.

As Azure Multi-factor Authentication information is stored in Azure AD only, and not written back to the on-premises Azure AD Connect or Active Directory environment, but is now used to integrate with on-premises systems, services and applications, now is a good time to look for a solution that creates backups of the Azure AD tenant.

Network requirements

The AD FS servers in the AD FS farm need to be able to communicate to the following urls over TCP port 443 (HTTPS):

PRIVILEGE REQUIREMENTS

Make sure to sign in with an account that:

  • Is a member of the Enterprise Admins group in Active Directory, and;
  • Has privileges to manage the AD FS farm.

Note:
In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS server.

Also, you’ll need the credentials of an account with the Global Administrator role in the Azure AD tenant in which you want to use Azure multi-factor authentication. If running these

WHO TO COMMUNICATE TO

If your users have not registered for Azure MFA yet, than this part of the implementation requires a communications plan.

 

How to enable Azure MFA on AD FS

Enabling Azure Multi-Factor Authentication on AD FS requires three steps:

  1. Register Azure MFA in the tenant
  2. Enable Azure MFA as AD FS Multi-factor Authentication method
  3. Choose an appropriate Access Policy per AD FS Relying Party Trust (RPT)

 

Register Azure MFA in the tenant

First, run the following lines of Windows PowerShell in an elevated PowerShell window on each of the AD FS servers in the AD FS farm:

Install-Module MSOnline

Connect-MsolService

Log in.

$TenantID = (Get-MsolCompanyInformation).ObjectID$Certbase64 = New-AdfsAzureMfaTenantCertificate –TenantID $TenantID

New-MsolServicePrincipalCredential -AppPrincipalId
981f26a1-7f43-403b-a875-f8b09b8cd720 -Type Asymmetric –Usage Verify  -Value $CertBase64

Then, on the primary AD FS server in the AD FS farm, run the following lines of Windows PowerShell:

Set-AdfsAzureMfaTenant -TenantId $TenantID -ClientId
981f26a1-7f43-403b-a875-f8b09b8cd720

 

Enable Azure MFA as AD FS multi-factor authentication method

Now that the Azure MFA Adapter is available as a multi-factor authentication mechanism, we need to enable it for the AD FS farm, again on the primary AD FS server.

Run the following lines of Windows PowerShell:

$C = (Get-AdfsGlobalAuthenticationPolicy).AdditionalAuthenticationProvider

$C.Add("AzureMfaAuthentication")

Set-AdfsGlobalAuthenticationPolicy -AdditionalAuthenticationProvider $C

 

Choose an appropriate Access Policy per Relying Party Trust

Each AD FS-integrated system, service and application has its own relying party trust (RPT) relationship with AD FS. In AD FS on Windows Server 2016, and above, you can enable multi-factor authentication with built-in access policies.

These policies are aptly named:

  • Permit everyone and require MFA for specific group
  • Permit everyone
  • Permit everyone for intranet access
  • Permit everyone and require MFA from unauthenticated devices
  • Permit everyone and require MFA from extranet access
  • Permit specific group
  • Permit everyone and require MFA, allow automatic device registration
  • Permit everyone and require MFA

Note:
You can add access policies yourself if none of the built-in access policies fit your organization’s needs.

By default, every relying party trust is not configured with an access policy, which is the equivalent of the Permit Everyone access policy. You can change it to another policy using the following line of Windows PowerShell:

$RPT = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform"

Set-AdfsRelyingPartyTrust
-TargetRelyingParty $RPT -AccessControlPolicyName "Permit everyone and require MFA from extranet access"

 

Testing Azure MFA on AD FS

After enabling the Extended Protection for Authentication feature,  it’s time to test.

The Permit everyone and require MFA for specific group access policy is the ideal method to test the correct registration and working of Azure MFA. Simply create a group in Active Directory, configure the access policy for a relying party trust with the access policy and the group. Then, add a user account that had previously registered MFA to the group and use it to sign in to the system, services or application that is represented by the relying party trust.

 

Concluding

One Multi-factor Authentication method for all your organization’s Azure AD- and AD FS-integrated systems, services and applications?

Yes, it’s possible!

Further reading

Configure AD FS 2016 and Azure MFA
Getting started with Azure Multi-Factor Authentication and AD FS
Securing cloud resources with Azure Multi-Factor Authentication and AD FS
AD FS 2016 and Azure MFA – a few Nuances
Step-by-Step guide to configure Azure MFA with ADFS 2016

Series Navigation

<< HOWTO: Enable Extended Protection for Authentication on the AD FS FarmHOWTO: Change the Security Response Headers on AD FS >>

2 Responses to HOWTO: Enable Azure Multi-factor Authentication on AD FS

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.