Active Directory Federation Services (commonly searched as ADFS and styled by Microsoft as AD FS) is an on-premises identity federation service in Windows Server. It authenticates users and issues signed, claims-based tokens that trusted applications use for single sign-on (SSO). As a result, users can access connected applications without sharing their Active Directory password with each one.
Microsoft documents AD FS for Windows Server 2016, 2019, 2022, and 2025. However, it recommends migrating applications to Microsoft Entra ID instead of upgrading AD FS. This makes AD FS relevant to many existing environments, but less likely to be the default choice for a new identity architecture.
Key takeaways
- AD FS enables identity federation and SSO: Active Directory Federation Services is an on-premises Windows Server service that provides claims-based access to trusted applications.
- It commonly works with Active Directory: AD FS authenticates users and issues signed tokens to trusted web, cloud, or partner applications.
- It supports multiple federation protocols: These include SAML, WS-Federation, OAuth, and OpenID Connect, depending on the Windows Server version and use case.
- AD FS remains supported: However, Microsoft recommends migrating applications to Microsoft Entra ID rather than upgrading AD FS.
- Modernization can extend beyond migration: Organizations can evaluate Scalefusion OneIdP for SSO, identity federation, MFA, directory integration, and UEM-driven conditional access.
What Is ADFS and What Does It Do?
Active Directory Federation Services (commonly called ADFS and styled by Microsoft as AD FS) is an on-premises identity federation service built into Windows Server. It commonly authenticates users through Active Directory Domain Services and issues signed, claims-based tokens that trusted applications use for single sign-on.
AD FS acts as a trust bridge between an organization’s identity system and its connected web, cloud, or partner applications. It extends corporate identities beyond the internal Windows domain without requiring each application to receive or manage the user’s Active Directory password.
For example, when an employee opens a partner portal, the portal redirects the employee’s browser to AD FS. After authenticating the employee, AD FS issues a signed token containing approved claims, such as a user ID, email address, role, or group membership. The portal validates the token and uses its own authorization rules to determine access.
This process is known as identity federation: separate systems establish trust without merging their user directories or exchanging passwords. An identity broker can help manage these trust relationships when multiple identity providers are involved.
How does ADFS work?
A typical AD FS sign-in follows six steps:
- The user opens an application. The application detects that the user does not have an active session.
- The application redirects the user to AD FS. The request identifies the application, known as the relying party.
- AD FS authenticates the user. It commonly verifies the user through Active Directory and applies the configured authentication policy.
- AD FS evaluates claim rules. These rules determine which user information the application may receive.
- AD FS issues a signed security token. The token can include claims such as the user’s identifier, email address, role, or group membership.
- The application validates the token. If the issuer, signature, audience, and validity checks pass, the application creates a session and applies its own authorization rules.
The application receives a token—not the user’s Active Directory password. Depending on the Windows Server version and use case, AD FS can support protocols including SAML 2.0, WS-Federation, OAuth 2.0, OpenID Connect, and WS-Trust.
Claims and federation trusts
A claim is a statement about a user, such as an email address or group membership. AD FS packages approved claims in a signed token. A federation trust defines which systems can exchange and accept this identity information. Relying party trusts represent applications that accept AD FS tokens; claims provider trusts represent identity sources whose claims AD FS accepts.
What are the main components of AD FS
| Component | Purpose |
|---|---|
| Active Directory Domain Services | Stores organizational identities and commonly authenticates users |
| Federation server | Processes sign-in requests, applies claim rules, and issues tokens |
| Federation server farm | Uses multiple servers for capacity and availability |
| Web Application Proxy | Optionally publishes AD FS for users connecting from outside the network |
| Configuration database | Stores trusts, claim rules, and farm configuration |
AD FS also relies on token-signing certificates. Applications use the corresponding public key to verify that tokens came from a trusted federation service and were not altered. Certificate storage, renewal, rollover, and access permissions therefore require careful management.
ADFS vs. Active Directory, LDAP, and SSO
| Term | What it is | Primary purpose |
|---|---|---|
| Active Directory | A directory service | Stores identities and manages Windows-domain resources |
| LDAP | A directory access protocol | Queries and updates compatible directories |
| SSO | An access capability | Lets a user authenticate once and access connected applications |
| AD FS | A federation and token service | Extends trusted identities to web, cloud, and partner applications |
AD FS does not replace Active Directory. It commonly relies on Active Directory to authenticate users, then converts the successful sign-in into a token an application can trust. LDAP provides direct directory communication, while AD FS provides claims-based federation.
What are the benefits and limitations of AD FS
| Benefits | Limitations |
|---|---|
| Provides SSO across trusted applications | Requires servers, patching, monitoring, backups, and capacity planning |
| Keeps Active Directory passwords away from relying applications | Claim rules, trusts, and application integrations need specialist knowledge |
| Supports standards-based federation | Certificate renewal or rollover errors can interrupt access |
| Keeps authentication under organizational control | High availability can require multiple servers, proxies, and load balancing |
| Supports legacy and partner federation scenarios | Federation servers and signing keys are high-value security targets |
AD FS does not automatically provision accounts, secure endpoints, or make an organization compliant. Those outcomes depend on the surrounding identity, endpoint, security, and governance controls.
Is ADFS Still Used—and What Is Replacing It?
Yes. AD FS remains in use where organizations depend on legacy applications, partner trusts, custom claim rules, or on-premises authentication. Microsoft continues to document the service for supported Windows Server releases, so AD FS is not deprecated.
Support, however, is different from strategic direction. Microsoft recommends moving AD FS applications to Entra ID where practical. Its AD FS decommission guidance covers application discovery, migration, authentication changes, and retirement of the infrastructure.
Security is another consideration. If an attacker compromises an AD FS environment and obtains its token-signing private key, the attacker may be able to forge trusted SAML tokens—a technique known as Golden SAML. Microsoft recommends restricting administrative access, keeping the environment current, monitoring configuration changes, and protecting signing keys. See Microsoft’s guidance for securing AD FS and mitigating Golden SAML attacks.
Before changing platforms, inventory every relying application, authentication protocol, claim rule, certificate, partner trust, and provisioning dependency. Some applications can move quickly; others may require remediation or phased coexistence.
Modernizing identity and access with Scalefusion OneIdP
Microsoft Entra ID is Microsoft’s recommended migration path for AD FS workloads. A broader identity review may also ask how SSO, identity sources, multifactor authentication, and device context should work together across an organization.
Scalefusion OneIdP is a UEM-driven identity and access management solution. It supports SSO for SAML- and OIDC-based applications, identity federation, directory integration, MFA, and contextual access policies. Its connection with Scalefusion UEM can bring managed-device and compliance context into access decisions.
AD FS and OneIdP are not one-for-one equivalents. Existing relying party trusts, claim rules, protocols, provisioning flows, and partner integrations need individual assessment before migration. The following table compares their overlapping identity and application-access roles.
| Area | AD FS | Scalefusion OneIdP |
|---|---|---|
| Primary role | Self-hosted federation for trusted applications | Centralized identity and application access with UEM-driven controls |
| Management | Operated on organization-managed Windows Server infrastructure | Managed through the Scalefusion platform |
| Identity sources | Commonly uses Active Directory and configured claims providers | Integrates with sources including Microsoft Entra, Google Workspace, Okta, and on-premises AD or LDAP, depending on the method |
| Application SSO | Supports protocols including SAML, WS-Federation, OAuth, and OIDC, depending on version | Supports SSO for SAML- and OIDC-based applications |
| Access decisions | Uses claims, authentication methods, trusts, and configured policies | Can use identity and contextual conditions such as device compliance, managed status, browser, network or IP, and location where configured |
| Best fit | Established Microsoft-centric or legacy federation requirements | Organizations evaluating modern SSO and device-aware access through a unified UEM and IAM approach |
Evaluate OneIdP identity federation, directory services, and enterprise SSO against your application and security requirements.
ADFS remains relevant—but modernization should be planned
AD FS provides claims-based federation and SSO for applications that trust an organization’s identities. It remains useful in established and legacy environments, but it brings infrastructure, certificate, and security responsibilities. Organizations should maintain necessary dependencies securely while planning their longer-term identity architecture.
Evaluate Scalefusion OneIdP for SSO, identity federation, MFA, directory integration, and UEM-driven conditional access.
FAQs
1. What is the difference between ADFS and Active Directory?
Active Directory stores identities and manages Windows-domain resources. AD FS commonly uses Active Directory to authenticate a user, then issues a signed token for a trusted application. In short, Active Directory maintains the identity, while AD FS extends that identity to federated applications.
2. Is ADFS still needed?
AD FS may still be needed when a legacy application, custom claim rule, partner trust, or on-premises requirement depends on it. If those dependencies do not exist, a cloud identity platform may reduce server and certificate-management work. Assess each connected application before deciding.
3. Is ADFS deprecated?
No. AD FS remains documented for supported Windows Server releases. However, Microsoft recommends migrating applications to Microsoft Entra ID instead of upgrading AD FS. Organizations should distinguish continued product support from Microsoft’s preferred direction for modern identity deployments.
4. What is replacing ADFS?
Microsoft recommends Entra ID as the migration direction for AD FS applications. A replacement decision should still account for application protocols, claims, directories, provisioning, partner connections, compliance requirements, and endpoint strategy. No platform should be treated as a drop-in replacement without this assessment.
5. What is the difference between ADFS and LDAP?
LDAP queries or updates directory information. AD FS issues claims-based tokens to trusted applications, allowing a web application to validate a token instead of sending the user’s password directly to a directory.
