ADFS Authentication: How It Works and 6 Key Requirements

Key takeaways

• ADFS enables single sign-on (SSO) across organizational boundaries, allowing users to access multiple applications with one set of credentials
• Supports a variety of authentication methods including forms-based login, Windows Integrated Authentication, certificate-based authentication, multi-factor authentication, and device trust
• Requires a complex setup involving certificates, Active Directory domain membership, SQL Server for large deployments, and Web Application Proxy for external access
• Ongoing maintenance is resource intensive with responsibilities like managing SSL certificates, configuring proxies, and applying security patches
• Lacks modern identity features such as remote desktop support, intuitive user management, and direct access to Active Directory resources
• Best suited for legacy environments and may no longer meet the needs of teams looking for a flexible and scalable CIAM solution

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 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.
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.

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. No support for remote desktop: Another notable limitation is the lack of support for remote desktop connections, which can be a significant drawback for organizations that rely on remote access for their workforce.

Rethinking ADFS for modern CIAM needs

ADFS helped shape enterprise authentication, but today its complexity, overhead, and dev-heavy maintenance model create more friction than value. Tasks like managing certificates and configuring proxies aren’t just operational—they slow teams down.

Modern identity should be easy to configure, simple to delegate, and responsive to change. If your CIAM still relies on ADFS, it may be time to ask whether it’s helping your teams or holding them back. The future of identity is flexible, distributed, and built for speed.