What AD FS Does
Active Directory Federation Services (AD FS) is a Windows Server role that extends single sign-on beyond a single Active Directory forest by issuing security tokens based on claims rather than direct password checks, enabling users to authenticate once and access trusted external applications like a partner company's extranet or a cloud SaaS product. Instead of the relying application validating a password directly, it trusts a signed token issued by the Federation Service, which itself vouches for the user after checking their credentials against Active Directory.
Cricket analogy: Like an ICC-accredited umpire's decision being trusted by a touring team's board without them re-checking every replay themselves, because the umpire's signed report is the trusted token of what happened.
Trust Relationships in a Federation
A federation deployment centers on two trust relationship types: a claims provider trust, which defines where AD FS gets identity information (typically the local AD DS forest), and a relying party trust, which defines the external application receiving tokens, such as a partner's SharePoint site or a SaaS vendor. Historically, AD FS also used a Federation Service Proxy, now replaced by the Web Application Proxy (WAP) role, to safely publish federation endpoints to the internet without placing the Federation Service itself in the DMZ.
Cricket analogy: Like a bilateral series being governed by two separate agreements — one defining how the touring board selects and vouches for players, another defining what the host board will accept from them.
Claim Rules and Token Types
Claims move through a pipeline of claim rules: an acceptance transform rule pulls attributes like the user's UPN or group membership from Active Directory, and an issuance transform rule maps those into outbound claims — such as an email claim or a role claim — that the relying party actually understands, often expressed in the AD FS claim rule language. AD FS commonly issues SAML 2.0 tokens for browser-based relying parties and can also speak WS-Federation or WS-Trust for older or specialized client integrations, with each token signed by a token-signing certificate the relying party has been configured to trust.
Cricket analogy: Like a scorer converting raw ball-by-ball data (accepted from the scoring machine) into the specific summary stats — strike rate, economy — that the broadcaster's graphics package actually needs to display.
// Acceptance transform: pull the user's UPN from Active Directory
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"),
query = ";userPrincipalName;{0}", param = c.Value);
// Issuance transform: map UPN to an outbound email claim for the relying party
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress", Value = c.Value);From the end user's perspective, federation is invisible: they sign into their corporate desktop once, then click a link to a partner's claims-aware portal and are logged straight in without ever seeing a second password prompt, because the browser silently redirects through the Federation Service to fetch a token.
Deploying AD FS in Production
A production AD FS deployment is typically built as a farm of two or more federation servers behind a load balancer for high availability, backed by either the Windows Internal Database (WID, limited to 30 nodes and no read-write replication) or a full SQL Server backend for larger farms; token-signing and token-decrypting certificates must be renewed and, ideally, auto-rotated before expiry or every relying party integration breaks simultaneously. Microsoft has been steadily steering customers away from on-premises AD FS toward Microsoft Entra ID for new federation scenarios, so AD FS today is mostly maintained for legacy claims-aware applications that cannot yet be migrated to cloud-native authentication.
Cricket analogy: Like a national board running a full multi-venue setup with backup grounds for a World Cup, versus a small local club running matches on a single field with no fallback if it rains out.
Microsoft has been actively steering new deployments away from on-premises AD FS toward Microsoft Entra ID's built-in federation and SSO capabilities. AD FS today is primarily maintained for legacy claims-aware applications and specific compliance scenarios that can't yet move to cloud-native authentication, so new AD FS farms should be a deliberate, justified exception rather than a default choice.
- AD FS issues signed security tokens based on claims instead of having relying applications check passwords directly.
- A claims provider trust defines where identity comes from; a relying party trust defines which application receives tokens.
- The Web Application Proxy (WAP) role safely publishes federation endpoints to the internet, replacing the older Federation Service Proxy.
- Claim rules run through an acceptance transform (pulling AD attributes) and an issuance transform (mapping to outbound claims).
- AD FS commonly issues SAML 2.0 tokens, and also supports WS-Federation and WS-Trust for legacy clients.
- Production farms need redundancy (multiple federation servers, a load balancer) and a SQL Server backend for scale beyond WID's limits.
- Microsoft now recommends Entra ID over on-premises AD FS for new federation scenarios.
Practice what you learned
1. What does a relying party trust define in an AD FS deployment?
2. What role replaced the older Federation Service Proxy for publishing AD FS to the internet?
3. Which token type does AD FS most commonly issue for browser-based relying parties?
4. What is a key limitation of using the Windows Internal Database (WID) for an AD FS farm?
5. Which two claim rule stages transform an on-premises AD attribute into an outbound token claim?
Was this page helpful?
You May Also Like
Hybrid Identity with Microsoft Entra Connect
How Microsoft Entra Connect synchronizes on-premises Active Directory identities to Microsoft Entra ID, and the authentication methods and safeguards that make hybrid identity work reliably.
Kerberos Authentication
How Active Directory's ticket-based Kerberos protocol authenticates users and services without repeatedly transmitting passwords, and how to diagnose its most common failures.
Securing Privileged Accounts (Tiered Admin Model)
How Microsoft's tiered administration model, Privileged Access Workstations, and LAPS together prevent a single compromised low-trust machine from escalating into full domain compromise.
Related Reading
Related Study Notes in Microsoft Technologies
Browse all study notesWindows 10 / UWP Development Study Notes
.NET · 30 topics
Microsoft TechnologiesWindows Batch Scripting Study Notes
Batch · 30 topics
Microsoft TechnologiesMFC (Microsoft Foundation Classes) Study Notes
C++ · 30 topics
Microsoft TechnologiesSilverlight Study Notes
.NET · 30 topics
Microsoft TechnologiesXAML Study Notes
.NET · 30 topics
Microsoft TechnologiesWPF (Windows Presentation Foundation) Study Notes
.NET · 30 topics