What Is AD FS? Federated SSO and Golden SAML

Steal one certificate from one server and you can sign in as anyone, with no password, no MFA prompt, and no failed-login event for the SOC to catch. That certificate lives on an AD FS server, and the technique that abuses it has a name: Golden SAML.

Active Directory Federation Services is the Microsoft component that brokers single sign-on between an on-premises Active Directory and external applications. It is useful, it is widely deployed, and it is a high-value target precisely because it issues the tokens that everything downstream trusts. This guide explains what AD FS is, how the federated sign-in flow actually works, where it breaks under attack, and why Microsoft now steers customers off it toward Entra ID. It is written for defenders who have to monitor an AD FS server, scope an incident that touches one, or decide whether the box should still be on the network.

What is AD FS (Active Directory Federation Services)?

AD FS is a server role in Windows Server that provides federated identity and single sign-on. It lets a user authenticate once against on-premises Active Directory and then access external or cloud applications without logging in again to each one. The applications never see the user's password. They see a signed token that AD FS issues on the user's behalf.

The model AD FS implements is called claims-based authentication. A claim is a statement about a user that AD FS asserts and signs: this is their user principal name, this is their email, these are their group memberships, this is the multi-factor method they used. The application, called the relying party, is configured to trust tokens signed by AD FS. It reads the claims, applies its own authorization rules, and grants or denies access based on what the token says.

Federation is the key word. AD FS does not replace Active Directory; it sits in front of it as a Security Token Service. Active Directory holds the identities and validates the password. AD FS converts a successful AD authentication into a signed token that a party outside the AD trust boundary, a SaaS application, a partner organization, a cloud service, will accept. That is what makes it single sign-on across organizational and protocol boundaries rather than just inside one domain.

AD FS speaks the open federation protocols so it can talk to applications that are not Windows-native. The main three are SAML 2.0 (Security Assertion Markup Language), WS-Federation, and OAuth 2.0 with OpenID Connect. SAML and WS-Fed carry the signed assertions for web SSO; OAuth and OpenID Connect cover modern app and API authorization. The protocol differs by application, but the core idea does not: AD FS authenticates the user against AD, then mints a signed token the application trusts.

How the AD FS sign-in flow works

The point of AD FS is one signed token crossing a trust boundary. Walk a single web SSO request through it and the moving parts become clear.

A user opens a SaaS application configured to federate with their organization. Because the application does not handle the password itself, it redirects the browser to the organization's AD FS endpoint with an authentication request. AD FS prompts the user, who submits credentials. AD FS validates those credentials against Active Directory, which is still the system of record for the password and account state.

On a successful check, AD FS builds the token. It gathers the user's attributes from AD, runs them through the relying party's claim rules to decide which claims to include, assembles a SAML assertion, and signs it with its private token-signing certificate. The browser carries that signed assertion back to the application. The application validates the signature against the AD FS public certificate it was configured to trust, reads the claims, and starts a session. The user is in, and never typed a password into the application.

The whole security model rests on step 5. The application trusts the token only because it trusts the signature, and it trusts the signature only because it was configured with the matching public certificate. Whoever controls the private token-signing key can produce assertions the application will accept. That single fact is what makes the attack section below possible.

In a hybrid deployment the relying party is often Microsoft 365 itself. AD FS federates the on-premises domain to Entra ID (formerly Azure AD), so users sign in to Microsoft 365 through the on-premises AD FS farm. Microsoft Entra Connect synchronizes the directory and originally wired up that federation trust. This hybrid pattern is exactly the configuration the SolarWinds intrusion abused.

The components

A production AD FS deployment is more than one box. The pieces that matter for an investigation:

• Federation server. The core AD FS role. It authenticates users, applies claim rules, and signs tokens. It holds (or accesses) the token-signing certificate's private key. This is the crown jewel.
• Federation server proxy / Web Application Proxy (WAP). A server in the perimeter network that relays authentication requests from the internet to the internal federation server, so the federation server itself is not directly exposed. It does not issue tokens.
• AD FS configuration database. Stores the farm configuration, relying party trusts, and claim rules. On a Windows Internal Database or SQL Server. Its contents tell an attacker every application that trusts this farm.
• Token-signing certificate. The private key that signs every assertion. The entire trust chain depends on its secrecy.
• Relying party trust. A configured relationship with one application that defines its endpoint, identifier, and claim rules.
• Active Directory and Microsoft Entra Connect. AD is the identity store; Entra Connect synchronizes it to the cloud and configures federation in hybrid setups.

AD FS and security: Golden SAML

The defensive problem with AD FS is structural, not a patchable bug. AD FS is the thing that issues trust. If an attacker gets administrative control of the federation server, they do not need to crack anyone's password again. They steal the token-signing certificate's private key and forge their own tokens. This technique is Golden SAML.

The attack runs in a sequence. The adversary first compromises the network and reaches the AD FS server through ordinary lateral movement and privilege escalation, ending with administrative rights on the box. From there they extract the AD FS token-signing certificate and private key, often alongside credential dumping for other accounts. With the private key off the server, the attacker can mint SAML assertions on their own infrastructure for any user they choose, with any claims they choose, including a claim that multi-factor authentication was satisfied.

The consequences are what make it dangerous. A forged Golden SAML token bypasses the password because no password check happens. It bypasses MFA because the token can simply assert MFA was done. And it produces no authentication event on the AD FS server, because no real authentication occurred; the token was signed offline. To a relying party such as Microsoft 365, the forged token is indistinguishable from a legitimate one. The access persists as long as the certificate is valid, which is often a year or more, and survives the victim resetting their password.

This is not theoretical. In the 2020 SolarWinds intrusion, the actor Microsoft tracks as NOBELIUM, attributed by the US government to the Russian SVR, compromised on-premises AD FS servers and deployed a backdoor Microsoft named FoggyWeb. Per Microsoft's threat intelligence, FoggyWeb was built to exfiltrate the AD FS configuration database, the decrypted token-signing certificate, and the token-decryption certificate from compromised servers. With those certificates, the actor forged SAML tokens to access cloud resources, including Microsoft 365, bypassing MFA. CISA's remediation guidance for that campaign describes the same technique: stealing the AD FS token-signing certificate to forge SAML tokens and move into Microsoft 365.

Detection has to account for the fact that the forgery itself is silent. Practical signals for a SOC:

• Watch the AD FS server like a domain controller. Token-signing certificate export, access to the configuration database, lsass access, and new local admin activity are the events that precede a forge. The forge is invisible; the theft that enables it is not.
• Correlate cloud sign-ins against AD FS logs. A Microsoft 365 sign-in that asserts it came through your federation but has no matching event on the AD FS server is a Golden SAML indicator. Microsoft Entra Connect Health and unified audit logs surface federated sign-ins for this comparison.
• Alert on anomalous token lifetimes and claims. Forged tokens often carry unusual validity windows or claim values that a normal AD FS issuance would not produce.
• Treat token-signing certificate access as a top-tier event. Restrict who can log on to the AD FS farm, and audit every certificate operation.

AD FS vs Entra ID

AD FS and Entra ID solve the same problem, SSO to applications, from opposite ends. AD FS is on-premises infrastructure you run, patch, and defend. Entra ID is Microsoft's cloud identity service, where the token-issuing infrastructure is Microsoft's responsibility and the high-value signing keys are not sitting on a Windows Server in your data center.

The security argument is the decisive one. Golden SAML exists because the token-signing key is a file on a server in your environment that an attacker can reach. Moving authentication to Entra ID removes that on-premises key from the equation. Entra ID also adds Conditional Access and Identity Protection, which evaluate sign-in risk in ways an AD FS farm cannot.

This is why Microsoft now steers customers toward Entra ID. Microsoft's official guidance is to migrate from federation to cloud authentication, using Password Hash Synchronization (PHS, the recommended method) or Pass-through Authentication (PTA), and then decommission the AD FS infrastructure. The stated benefits include reducing on-premises footprint, gaining cloud security features, and removing the AD FS attack surface. Where an organization still has applications that need SAML, WS-Fed, or OAuth and cannot move them immediately, Microsoft points to Secure Hybrid Access through Microsoft Entra application proxy rather than keeping AD FS as the primary authentication path.

For a defender, the takeaway is direct: AD FS on your network is a self-hosted token-signing key that an attacker who reaches the box can turn into organization-wide forged access. If it is still there, it belongs in the same monitoring tier as a domain controller, and migrating it off is a security improvement, not just an IT modernization.

Where AD FS still fits

AD FS is not dead, and plenty of environments still run it for good reasons. Organizations with strict data-residency rules may need authentication to stay on-premises. Some legacy or third-party applications federate only through AD FS and cannot yet move to Entra ID. Some deployments use AD FS claim rules and customizations that have no direct cloud equivalent.

In those cases the model holds, but the defensive posture has to match the risk. An AD FS farm that has to stay should be treated as Tier 0 identity infrastructure: minimal administrative access, certificate operations audited, the configuration database protected, and federated sign-ins correlated against the cloud. The same authentication context that makes NTLM vs Kerberos a core Active Directory topic applies here, AD FS is the federation layer on top of that same identity store, and it inherits the same need for tight control.

The bottom line

AD FS is Microsoft's on-premises federated SSO service. It converts a successful Active Directory login into a SAML, WS-Fed, or OAuth token that external applications trust, using claims and a token-signing certificate. The model works, and it is everywhere in hybrid Microsoft environments.

The same design that makes it useful makes it a prime target. The token-signing key sits on a server you operate, and an attacker who reaches that server can forge tokens that bypass passwords and MFA without leaving an authentication trail, the Golden SAML technique proven in the SolarWinds intrusion. That is why Microsoft now recommends migrating to Entra ID, and why any AD FS farm that stays on the network has to be defended like a domain controller.