Updated on August 15, 2024
Active Directory Federation Services (AD FS) is an on-premises authentication technology for Windows Server operating systems. It extends single sign-on (SSO) capabilities to applications that are not compatible with Windows Active Directory (AD) and Integrated Windows Authentication (IWA).
Microsoft released AD FS as a response to increasing demand for SSO capabilities for third-party software-as-a-service (SaaS) technologies in the 2000s. The need to create a “trust relationship” between different web-facing applications and cloud environments has only grown since then.
AD FS allows organizations to create a network of trust between one another across the internet. It complements Active Directory by extending on-premises user identities to cloud-hosted applications and workloads.
What Are the Different Parts of AD FS?
AD FS is made of four primary components:
- Active Directory. This is where AD FS’s identity information gets stored. AD FS extends AD’s information beyond the enterprise’s network. This allows users to access Windows-based and third-party applications while outside of corporate networks.
- Federation server. This component issues security tokens that manage federated trusts between business partners. The federation server processes authentication requests from external users and issues out security tokens for claims based on credentials stored in AD.
- Federation server proxy. This is deployed on the organization’s extranet and links external users and the federation server. This way, the federation server does not get exposed directly to the internet, which mitigates security risks.
- AD FS web server. This component hosts the AD FS Web Agent, a service that either allows or denies a user access to web applications based on authentication cookies and security tokens sent to it.
How Does AD FS Work?
AD FS uses claim-based authentication, which verifies users by drawing from a set of “claims” about their identity from a trusted token. This gives users a single SSO prompt that allows them to access multiple applications and systems on different networks.
In practice, it functions in broadly the same way as any web application-based SSO service using the Secure Assertion Markup Language (SAML) protocol. AD FS can also use cookies and other token standards such as JSON web tokens (JWT) to authenticate users, but it’s leveraged in on-premises setups instead of the cloud.
When organizations adopt AD FS, they establish a system of identity federation that confirms trust between two security environments. A federation server in one organization authenticates users through standard Active Directory Domain Services (AD DS) and then issues a token that the other organization can recognize and confirm.
Upon recognizing and confirming the security token, the other organization issues its own token that allows local servers to accept the claimed identity. It can now provide controlled access to internet-connected resources without requiring users to authenticate directly to each application individually.
The diagram below summarizes the workflow for AD FS-based systems:
Why Do Organizations Use AD FS?
Prior to 2003, organizations largely used AD and IWA to manage end-user access to corporate resources. As remote access and cloud-based services became more popular, it was apparent that AD and IWA could not cope with modern authentications. This was because users in such environments often want to access applications that are not company owned such as SaaS and web applications.
To do this, users would have to repeatedly sign into these applications manually. This added a significant amount of time-consuming complexity to enterprise workflows that required managing multiple third-party applications. Users would have to create accounts for each one and input their login credentials every time they wanted to use them.
AD FS resolved and simplified third-party authentication challenges, allowing organizations to better manage access to resources in an evolving workplace. With AD FS, users got authenticated to all the approved third-party systems and applications once they logged in with their Windows credentials.
Because of the SSO feature, users didn’t have to remember unfamiliar and disparate account credentials when accessing SaaS and web applications. Besides users, AD FS also provides benefits to IT administrators and developers alike. For example, IT administrators could largely maintain their existing AD setup, especially if other aspects of their environment were still largely on-premises, Windows-based infrastructure.
AD FS granted system administrators complete visibility over the digital identities of users. It also provided developers with a simplified solution for authenticating users through their identities in the organization’s directory, allowing them to spend more time focused on high-impact production tasks.
What Are the Limitations and Disadvantages of AD FS?
Although AD FS was popular when most IT environments relied on Microsoft Active Directory, it now presents several problems and limitations that can’t be ignored.
Today’s organizations have far more complex cloud deployments than what was possible in the early 2000s. In a modern enterprise context, AD FS solves some federation identity challenges but introduces several others.
1. High implementation and maintenance costs
Technically AD FS is free because it’s included in the Windows Server operating system. That means that organizations using Windows can deploy AD FS without having to buy a separate federation solution to support SSO capabilities.
However, the story is different in practice. Configuring your IT environment to support on-premises SSO servers for high availability use outside the network perimeter involves additional costs. These costs are often not immediately apparent, leading to surprise sticker shock when IT leaders find out how much AD FS actually cost them.
For example, the initial configuration and setup process must also include hardware server costs. AD FS will also generate ongoing maintenance costs that include infrastructure maintenance, secure sockets layer (SSL) certificates, and federation management.
These costs can be difficult to quantify. In many cases, they are expressed in reduced productivity and IT efficiency. The increase in demand for IT employee hours can drive human resource costs up as the organization seeks to hire new talent to cover its productivity deficits.
2. Complex hardware requirements
AD FS is not a cloud-native solution. It relies on multiple hardware components and applications. The on-premises element of your AD FS implementation will require extensive configuration and ongoing maintenance.
The three hardware components that make up AD FS include:
- The AD FS server, which establishes directory federation and enables single sign-on.
- The federation service proxy, which is installed between the AD FS server farm and the external resources it connects to.
- The AD FS configuration database, which defines the parameters that the federation service uses to identify partners, certificates, claims, and other data.
These components require deep technical expertise to deploy, configure, and maintain. Since AD FS is an on-premises solution, your in-house IT team will have to take on that burden.
At the same time, AD FS doesn’t include a user-friendly portal for managing identities and authentication policies. That means that adding an application or system to the service is often complex and time-consuming.
3. Inadequate security against modern threats
As the linchpin between the organization’s network and its various cloud-based services such as Office 365, AD FS makes an attractive target for threat actors. Compromising this system could grant access to any of your cloud-based data and assets.
While AD FS itself does not suffer from severe security flaws, the complexity of securing AD FS can make it a key vulnerability. Since it is an on-premises solution, your in-house IT team is responsible for keeping it secure against new and emerging threats — which is often easier said than done.
Attackers may try to forge SAML tokens and use them to compromise cloud-based assets. They may insert themselves between servers and nodes, or intercept SSL certificate requests using man-in-the-middle (MiTM) attack strategies.
These are not insurmountable security challenges. However, overcoming them is a time-consuming task that relies on specialist expertise. It’s easy for IT leaders to overlook these security considerations and leave cloud-based assets exposed to attack.
4. No native access to on-premises files and print servers
Windows Server file sharing and Active Directory provide complementary services for users in on-premises IT environments. However, in cloud-based environments with remote employees, these components may no longer work together as intended.
In order to grant remote users access to on-premises files and print servers, those assets must be converted to shared folders on the cloud. Those cloud-based folders must be governed by the same security policies that Active Directory implements in the on-premises environment.
Without AD FS-enabled file and print sharing mechanisms in place, users may resort to sharing files through consumer file sharing platforms like Dropbox or Google Drive. This creates a shadow IT scenario where your security team has no visibility into the data being shared on non-approved applications and platforms.
This can lead to threat actors leveraging unknown vulnerabilities against your organization. It can also expose your organization to compliance violations if data is not being securely stored in accordance with regulations.
5. Incompatibility with many Linux and macOS applications
AD FS was originally conceived for Windows-centric environments with a relatively small number of third-party web applications and services. Modern organizations do still rely on MIcrosoft Windows, but it is increasingly just one part of a larger, more complex whole.
Many SaaS applications now run on Linux and macOS platforms. AD FS is not well-equipped to natively deploy and control access to these resources. This adds significant complexity to the IT environment, and makes it difficult for IT leaders to ensure single sign-on is enabled across disparate applications and assets.
This is one of the main reasons why many modern organizations are transitioning to cloud-based AD FS alternatives that provide complete identity and access management (IAM) with single sign-on capabilities to virtually all IT resources. This is the kind of platform that today’s IT leaders truly need.
Is There a Better Alternative to AD FS?
IT leaders need a flexible IAM and single sign-on solution that allows for complete identity control while connecting users to all of the IT resources they need. The JumpCloud Directory Platform houses all of the capabilities you need to manage users regardless of location, protocol, platform, or provider.
Find out how simple migration from AD FS to JumpCloud can be and start deploying secure, cloud-native single sign-on to all of your applications and assets. You have the flexibility to use JumpCloud in whatever way you prefer, whether as an extension for Active Directory or a full-scale modern replacement for AD.
Leverage JumpCloud’s complete cloud IAM platform with SSO, MFA, and conditional access capabilities that enable users to securely and efficiently connect to every IT asset in your network. Establish a single IAM solution for connecting with Mac, Windows, Linux devices, Wi-Fi networks, VPNs, cloud and legacy apps, physical and virtual file servers, and more.
Check out our guided simulations to get a feel for what JumpCloud is capable of, or schedule a demo for a walk-through tailored specifically to your IT needs.