How to implement ADFS MFA (and when to choose a simpler path)

If you manage an on-premises or hybrid Active Directory environment and need on-prem multi-factor authentication (MFA), chances are someone has pointed you toward Active Directory Federation Services (ADFS). For years, ADFS MFA has been one way to add strong authentication to AD-connected resources. While Microsoft now recommends decomissioning ADFS and migrating to Entra ID, that doesn't always reflect the operational realities in play.

Here, we'll look at how to implement ADFS MFA and what deployment actually requires. We'll also explore why many IT teams, especially those whose primary goal is to secure Windows logins and remote access, find that UserLock gets them there faster, with less cost and no cloud dependency.

Active Directory Federation Services (ADFS) is a Windows Server role that enables federated identity and single sign-on (SSO) across organizational boundaries. In plain terms: it lets users authenticate against your on-premises Active Directory and then get access to external applications: Microsoft 365, Salesforce, or any SAML 2.0 / WS-Federation-compatible service, without re-entering credentials.

ADFS is not an MFA product. It's a federation and SSO service that supports MFA as part of its authentication policy. If you deploy ADFS to get MFA, you're essentially building a federation infrastructure to solve an access control problem.

That distinction matters, because the setup cost reflects it.

ADFS supports MFA through pluggable authentication adapters. When a user attempts to access a federated application, ADFS evaluates its authentication policy and, if MFA is required, prompts for a second factor before issuing the token.

Implementation follows the same basic sequence regardless of which adapter you choose.

There are three main options:

• Microsoft Entra MFA adapter: the most common choice for Microsoft-aligned environments. Available from ADFS 2016 onward. Requires your on-premises AD accounts to be synchronized to a Microsoft Entra tenant (the free Entra ID tier is sufficient). Users must pre-register for Entra ID MFA before they can authenticate through ADFS. Self-service enrollment doesn't happen automatically through ADFS itself.

• Third-party adapters: some vendors publish ADFS connectors that register as additional authentication methods. These can be helpful if you want to consolidate MFA across multiple systems or avoid a cloud dependency on Entra.

• Certificate-based authentication: built into ADFS as a default second factor option (smart card or PKI certificate). Viable in environments already running PKI infrastructure, but operationally heavy for most organizations.

Each adapter has its own installation process, but the end result is the same: the adapter registers itself as an authentication provider within ADFS. You can verify it's registered in the ADFS Management console under Service > Authentication Methods.

Open the ADFS Management console and navigate to Authentication Policies. You have two options:

• Global policy: requires MFA for all users across all relying party trusts. Simplest to configure, but applies uniformly.

• Per-relying-party policy: scopes MFA to specific applications or services. Lets you require MFA for sensitive apps (say, a financial system) while leaving others unaffected. You can also scope by AD group, requiring MFA only for specific user populations.

Select your additional authentication method (the adapter you installed in step 2) and apply the policy.

Before rolling out broadly, test with a pilot user against a non-critical relying party trust. The user should complete primary authentication (AD username and password), then be prompted for the second factor via whichever method your adapter provides. Confirm the flow works for both internal and external access if you're running a Web Application Proxy.

Many IT teams run the numbers and pause. ADFS isn't a lightweight install. A production-ready ADFS deployment requires:

• SSL certificate for the federation service endpoint

• Token signing certificate (and a backup. Microsoft explicitly warns that losing this makes ADFS unstable)

• Token encryption/decryption certificate

• Configuration database, either Windows Internal Database (WID) or SQL Server for larger farms

• Web Application Proxy (WAP) if you need to handle external authentication requests

• DNS configuration for both internal and external resolution

• Load balancer for any multi-server farm setup

• Domain controllers accessible to the ADFS farm

Each of these introduces a dependency and a potential point of failure.

Microsoft's own ADFS troubleshooting documentation covers certificate issues, SQL connectivity, integrated Windows Authentication failures, and Entra ID integration problems as primary categories, which paints a reasonable picture of where things tend to go wrong.

For organizations that already have ADFS running, adding MFA is a reasonable incremental step. For organizations looking into ADFS specifically to get MFA for on-prem AD, it's a big detour.

This is the most important thing to understand before committing to an ADFS-based MFA deployment.

ADFS MFA fires at the federation layer. It applies to authentication flows that pass through ADFS, which means SAML and WS-Federation-brokered access to federated applications. When a user logs into Microsoft 365 or a SAML-connected SaaS app through your ADFS farm, MFA can be required.

It does not apply to:

• Windows workstation and server logon

• RDP and Remote Desktop connections

• VPN authentication (unless separately configured via NPS/RADIUS)

• IIS-hosted applications not published through WAP

• Direct LDAP authentication from internal applications

• Any application that authenticates directly against AD rather than through federation

For many organizations, those uncovered paths, especially Windows logon and RDP, are the primary attack surface they're trying to protect. Compromised credentials used to log directly into a server or jump via RDP bypass ADFS entirely.

If your MFA requirement comes from a cybersecurity compliance standard (CMMC, HIPAA, PCI DSS, NIS2) or a cyber insurance policy, check whether ADFS coverage alone satisfies the scope. In many cases, those frameworks require MFA at the point of authentication to systems and data, not just at the SSO layer.

If your goal is to implement MFA on all access to your AD environment without building federation infrastructure, UserLock is built specifically for that.

UserLock sits at the AD authentication layer and enforces MFA directly on the connection types that matter most to on-prem and hybrid environments:

• MFA for Windows login — workstations and servers

• MFA for RDP and RD Gateway

• VPN (via RADIUS)

• IIS web applications

• RD Web

• RemoteApp

• UAC elevation

• MFA for SaaS apps like Microsoft365, ServiceNow, and Salesforce

UserLock deploys alongside your existing Active Directory. This means there's no new directory to manage, no architectural changes, and no cloud dependency. Policies map directly to your existing AD users, groups, and OUs. Installation requires Windows Server 2012 or later.

UserLock also supports Active Directory SSO for cloud applications using existing Windows AD credentials, so if federated access to SaaS apps is part of your requirement, that's covered too, without standing up an ADFS farm.

For MFA methods, UserLock supports authenticator apps (Google Authenticator, Microsoft Authenticator, and others), push notifications, and hardware keys including YubiKey and Token2.

One capability worth highlighting for remote or high security environments: UserLock MFA works without an internet connection, and extends to off-domain machines via UserLock Anywhere. If a user connects from outside the corporate network, MFA is still enforced, even without a VPN connection established first.

To be clear: ADFS is the right tool in some situations.

If you're already running ADFS for federated SSO and want to add MFA to that layer, deploying an MFA adapter is a sensible incremental step, and the guidance earlier in this article covers how to do that.

If your environment has specific requirements around SAML federation with partners or customers that can't be met another way, ADFS may be necessary infrastructure regardless.

Keep in mind that Microsoft has been steering organizations toward Entra ID for new deployments. ADFS remains available in Windows Server 2025 and has no announced end-of-life date, but it's no longer receiving new feature investment.