ADFS Authentication: How It Works and 6 Key Requirements

ADFS (Active Directory Federation Services) is a Microsoft Windows Server role that gives users single sign-on to web apps with their Active Directory account. ADFS checks the user's password against Active Directory, then sends the app a signed token over SAML, WS-Federation or OpenID Connect, so the app never sees the password. ADFS is still supported in Windows Server 2025, but Microsoft now highly recommends moving to its cloud service, Microsoft Entra ID, instead of upgrading ADFS.

Key takeaways

• ADFS is an on-premises Windows Server role for single sign-on and federation with Active Directory accounts.
• It issues SAML, WS-Federation and OpenID Connect tokens, so apps never handle users' passwords.
• ADFS still runs on Windows Server 2016 through 2025, with no announced end-of-support date, but Microsoft “highly recommends” migrating to Microsoft Entra ID instead of upgrading.
• The ADFS sign-in test page is https://<your ADFS host>/adfs/ls/idpinitiatedsignon.aspx. It's turned off by default.
• If you build a SaaS app, enterprise customers with ADFS or Entra ID will expect you to support SAML or OIDC single sign-on.

What is Active Directory Federation Services (ADFS)?

ADFS is a Microsoft service that provides directory and single sign-on (SSO) capabilities to users across organizational boundaries. By leveraging ADFS, organizations can allow users to access multiple applications with a single set of credentials. 

This federated identity management system reduces the need for multiple passwords. It supports secure cross-platform authentication, making it useful for diverse infrastructure requirements. It can help enterprises integrate cloud services and external partners into their existing IT environment.

ADFS allows single sign-on and identity federation across company borders. It enables trustworthy identity relationships between organizations, improving security and user experience while simplifying management. Unlike traditional directory services, ADFS uses standard authentication protocols, such as WS-Federation, OAuth, and SAML, to authenticate users from multiple domains. 

In this article:

ADFS authentication flows: How does ADFS work? 

ADFS enables single sign-on by acting as an intermediary between Active Directory (AD) and applications that do not directly support Integrated Windows Authentication (IWA). This is achieved through a federated trust, which links ADFS with the target application to enable secure access without requiring users to authenticate multiple times.

Here is how the authentication process works:

1. User request: The process begins when a user navigates to a specific URL provided by the ADFS service to access an application.
2. Authentication by ADFS: ADFS verifies the user’s identity by authenticating against the organization’s AD service, ensuring that the user is legitimate.
3. Issuing an authentication claim: Once the user is authenticated, ADFS generates an authentication claim. This claim serves as proof of the user’s identity and contains relevant information about their permissions.
4. Access to the application: The user’s browser forwards this claim to the target application. Based on the federated trust established between ADFS and the application, the claim is either accepted or rejected, granting or denying access accordingly.

ADFS login: the sign-in page URL

Most users never visit ADFS directly. They open an app, the app redirects them to the ADFS sign-in page, and ADFS sends them back with a token.

To test ADFS or let users pick an app from a list, ADFS has an IdP-initiated sign-on page:

https://<your ADFS host>/adfs/ls/idpinitiatedsignon.aspx

For example, https://sts.contoso.com/adfs/ls/idpinitiatedsignon.aspx. Since ADFS in Windows Server 2016, this page is disabled by default. An admin can turn it on with PowerShell:

Set-AdfsProperties -EnableIdpInitiatedSignonPage $true

ADFS authentication methods 

Active Directory Federation Services (ADFS) supports several authentication methods to accommodate different security requirements and user scenarios. These methods range from traditional username and password authentication to more secure MFA.

1. Forms-based authentication: Forms-based authentication is the default method for external users. It requires users to enter their credentials (username and password) on a web form. This method is suitable for web-based access and supports both internal and external users.
2. Windows Integrated Authentication (WIA): WIA is typically used for internal users within a corporate network. It leverages the existing Windows authentication system to provide a single sign-on experience. Since users are already authenticated to Active Directory, they do not need to enter their credentials again when accessing ADFS-protected applications.
3. Certificate-based authentication (CBA): Certificate-based authentication uses a digital certificate, typically stored on a smart card or a device, to verify a user’s identity. This method improves security by ensuring that only devices with valid certificates can authenticate, which is useful for highly sensitive environments.
4. Multi-factor authentication (MFA): ADFS supports multi-factor authentication, requiring users to provide additional verification beyond their password. MFA can be enforced for specific applications, user groups, or conditions (e.g., external access). Common second factors include one-time passcodes (OTP) sent via SMS or generated by an app, and biometric authentication. ADFS doesn't include its own second factor. It uses MFA adapters, such as Microsoft Entra multifactor authentication or a third-party provider. The older on-premises Microsoft MFA Server stopped handling MFA requests on September 30, 2024, so ADFS deployments that used it need cloud-based Entra MFA or another adapter.
5. Device authentication: Device authentication allows ADFS to verify that the device a user is logging in from is registered and trusted. This method can be used in conjunction with other forms of authentication to provide an additional layer of security, particularly for bring-your-own-device (BYOD) environments.

Related content: Read our guide to 2FA vs MFA

ADFS requirements 

Deploying ADFS requires a careful alignment of several infrastructure, software, and security components. Below are the key requirements organizations must meet to ensure a stable and secure ADFS environment.

1. Certificate requirements

Each ADFS and Web Application Proxy server must have a TLS/SSL certificate to support HTTPS communication. These certificates must be publicly trusted in production environments and should include the correct subject or SAN entries (e.g., fs.contoso.com). For user certificate authentication and device registration, SANs such as certauth.fs.contoso.com and enterpriseregistration.<upn suffix> are required.

Token signing and encrypting certificates are also essential for issuing and validating claims securely. ADFS can use self-signed certificates or certificates issued by an enterprise PKI. If these certificates change, all relying parties and claims providers must be updated to avoid authentication failures.

2. Hardware and software requirements

Minimum hardware includes 2 GB RAM and 32 GB disk space, though 4 GB RAM and 100 GB disk space are recommended. CPU capacity should be assessed based on expected load using Microsoft’s capacity planning tools.

SQL Server is necessary for configurations exceeding 100 relying party trusts or 30 ADFS nodes. Otherwise, the Windows Internal Database (WID) may suffice. SQL Server also enables features like token replay detection, which are not supported with WID.

3. Proxy and network requirements

For external (extranet) access, the Web Application Proxy role must be installed on separate servers. These proxies must support the MS-ADFSPIP protocol. The federation and proxy servers must not share the same machine.

Network configurations require opening TCP port 443 between clients, proxies, and federation servers. For scenarios using client certificates on port 443, port 49443 must also be open. DNS and firewall settings must ensure clients and proxies can resolve the federation service name correctly.

4. Active Directory requirements

ADFS servers must be joined to an Active Directory domain, and all servers in a farm must reside in the same domain. The farm setup depends on having access to the Primary Domain Controller (PDC).

All user domains must be trusted by the domain where the ADFS servers reside. The ADFS service account needs read access to user attributes across all trusted domains and forests. At least one domain controller must be running Windows Server 2016 for advanced features like Windows Hello for Business.

5. Configuration and permissions

Admins can use either standard or group-managed service accounts. Proper service permissions, such as “Log on as a service” and “Generate security audits,” are mandatory for ADFS to operate.

For browsers interacting with ADFS, JavaScript and cookies must be enabled. Browsers must support TLS/SSL client certificate authentication and Server Name Indication (SNI).

6. Load balancer requirements

Load balancers must not terminate TLS/SSL connections and should support SNI. HTTP-based health probes should be used for node monitoring. DNS round-robin and session affinity are not recommended due to potential traffic imbalances or failure handling limitations.

Is ADFS deprecated? ADFS and Microsoft Entra ID

No. ADFS is not deprecated. It's a supported role in Windows Server 2016, 2019, 2022 and 2025, and Microsoft hasn't announced an end-of-support date. But Microsoft's direction is clear: its AD FS documentation says that instead of upgrading to the latest version of ADFS, Microsoft “highly recommends” migrating to Microsoft Entra ID (formerly Azure Active Directory).

Microsoft backs that with migration tooling. Entra ID shows a recommendation to migrate apps from ADFS when it finds ADFS apps that can move, and an AD FS application migration tool, generally available since 2024, checks which apps are compatible and tracks the migration.

One related change affects many ADFS farms: the Windows Internal Database (WID), which small ADFS deployments use to store their configuration, is on Microsoft's list of features no longer in development and will be removed in a future Windows release. Microsoft suggests SQL Server instead.

Sources: AD FS overview, Migrate apps from ADFS to Microsoft Entra ID, Windows Server features no longer in development.

What are the limitations of ADFS? 

ADFS has several limitations that organizations should consider before implementing it.

1. Maintenance costs: ADFS requires significant maintenance efforts, including managing the infrastructure, maintaining multiple federations, and handling SSL certificates. These ongoing costs can be high, particularly in large or complex environments.
2. Complex configuration: Setting up ADFS and integrating new applications or systems is often a complex and time-consuming process. The service lacks a user-friendly interface, making it difficult to manage users, groups, and authentication policies.
3. Security risks: Since ADFS operates on Windows Server, it is vulnerable to common security threats, such as malware attacks. This requires regular updates and patches to ensure the system remains secure.
4. Limited feature set: ADFS does not support several functionalities that may be critical to some organizations. For example, it does not allow file sharing or printing through print servers, nor can it access Active Directory resources directly.
5. Moving off it takes planning. Each app has its own relying party trust and claims rules, so migrating to Entra ID or another identity provider means moving app by app.

Rethinking ADFS for modern CIAM needs

ADFS was built for a company's own employees signing in to the company's apps. A B2B SaaS product faces the opposite problem: many customer companies, each with its own identity provider, some on ADFS, most moving to Entra ID or Okta.

Frontegg is customer identity and access management (CIAM) for B2B SaaS. Your customers connect their identity provider to your app over SAML or OIDC, which ADFS and Entra ID both support, and can provision users with SCIM. Each customer's admins set up their own SSO from an admin portal inside your product, so a customer's move from ADFS to Entra ID doesn't need your engineering team. Frontegg is free up to 7,500 monthly active users, including 5 SSO/SCIM connections.

FAQ

Is ADFS being deprecated?

No. ADFS is supported in Windows Server 2016 through 2025, and Microsoft hasn't announced an end-of-support date. Microsoft recommends migrating to Microsoft Entra ID instead of upgrading ADFS.

What is the ADFS login URL?

The ADFS sign-in test page is https://<your ADFS host>/adfs/ls/idpinitiatedsignon.aspx. It's disabled by default since Windows Server 2016; admins enable it with Set-AdfsProperties -EnableIdpInitiatedSignonPage $true.

What is the difference between Active Directory and ADFS?

Active Directory stores user accounts and authenticates them inside the company network. ADFS sits in front of Active Directory and lets those accounts sign in to web apps, including apps outside the network, through SAML, WS-Federation or OpenID Connect.

What is the difference between ADFS and Entra ID?

ADFS is software you run on your own Windows Servers. Microsoft Entra ID is Microsoft's cloud identity service and does the same single sign-on job without servers to maintain, plus built-in MFA and Conditional Access. Microsoft recommends Entra ID for new deployments.

Does ADFS support MFA?

Yes, through MFA adapters such as Microsoft Entra multifactor authentication or third-party providers. The on-premises Microsoft MFA Server stopped working on September 30, 2024.

How does a SaaS app support customers who use ADFS?

Support SAML 2.0 or OpenID Connect single sign-on. The customer's ADFS admin adds your app as a relying party trust, and your app trusts their ADFS signing certificate. The same setup works when the customer moves to Entra ID.