Golden SAML still threatens hybrid identity via AD FS token-signing keys. Learn how to harden DKM access, detect key theft, and lock down federation servers.
Why Golden SAML Still Haunts Hybrid Identity: Hardening AD FS Token-Signing Keys and DKM Access
Active Directory Federation Services remains a high-value target for advanced attackers more than eight years after researchers first formalized the Golden SAML technique. When an adversary steals the private key that signs federation tokens, they can forge SAML assertions accepted by Microsoft 365, Entra ID, AWS, and other relying parties—often without triggering password or multifactor authentication checks. The attack does not require a brand-new remote code execution bug. It requires control of cryptographic material that AD FS was designed to protect, combined with the configuration debt that still accumulates on many hybrid estates.
In 2017, CyberArk Labs described Golden SAML as the federation-era counterpart to a Kerberos golden ticket. An attacker who obtains the token-signing private key can mint authentication objects that impersonate any user, assert any claims, and persist long after passwords change. The technique is not a protocol vulnerability in SAML 2.0 itself. It is an identity-provider forgery attack: whoever holds the signing key effectively becomes the identity provider for every service that trusts that key. Subsequent public research and incident response work, including analysis of the SolarWinds campaign, showed how the same pattern can convert an on-premises foothold into durable cloud access.
How Token-Signing Keys Are Protected
AD FS stores token-signing and token-decryption certificates so that the service can produce and consume federation tokens. In many deployments the private keys are protected with material managed through Active Directory’s Distributed Key Manager. Threat-hunting documentation shows the DKM container commonly living under a path such as CN=ADFS,CN=Microsoft,CN=Program Data,DC=<domain>, with key material frequently held in a contact object’s thumbnailPhoto attribute.
An attacker who can read that material, or who can export the signing certificate from the AD FS configuration store after decrypting it, gains the ability to sign arbitrary SAML responses. Tools historically associated with this workflow include ADFSDump-style utilities and PowerShell modules that export signing certificates once the necessary secrets are available. The operational implication is straightforward: the DKM container and the AD FS service account sit at tier-0. Overly broad access-control lists, inherited rights granted to backup or monitoring tools, and interactive logon rights on federation servers all enlarge the path from a limited compromise to identity control.
Microsoft’s published guidance treats AD FS servers as critical infrastructure. Recommended practices include limiting local Administrators membership to Active Directory and AD FS administrators only, placing computer objects in a dedicated organizational unit, protecting signing certificates against theft, considering hardware security modules for signing keys, and using group-managed service accounts with long, complex secrets. Extended protection for authentication, congestion control on the Web Application Proxy, and a minimal set of proxy-enabled endpoints further reduce the external attack surface.
Historical Flaws and Recurring Themes
AD FS has accumulated a series of documented security issues over the years. Public records include security-feature-bypass cases such as improper handling of banned IP lists, extranet lockout policy bypasses, and multifactor authentication request handling problems. Separate issues have involved server-side request forgery and other logic flaws. None of these individual CVEs is required for Golden SAML once signing keys are stolen; they illustrate, however, that federation components repeatedly attract both local and remote research attention.
What unifies the high-impact cases is privilege and key material. Attackers who already possess domain or service-level access treat AD FS as a pivot rather than an initial entry point. Forged tokens then bypass many of the controls organizations assume protect cloud workloads. Password resets, conditional access policies that still trust the federation relationship, and MFA challenges that occur only at the identity provider can all be sidestepped if the assertion itself is cryptographically valid.
Detection and Hunting Priorities
Because successful key theft can be quiet, detection must focus on access to the secrets and on anomalous federation behavior.
Directory Service Access auditing (Event 4662) on the DKM container and related contact objects is a practical starting point. Security teams can attach SACLs that record successful GenericRead access, then enrich events that reference the thumbnailPhoto attribute GUID. Unexpected principals reading those objects deserve immediate investigation.
On the AD FS hosts themselves, teams should watch for certificate export activity, unusual service-account logons, configuration database access, creation of new relying-party trusts, and claims-rule modifications. Correlating AD FS authentication logs with Entra ID and Microsoft 365 sign-in telemetry helps surface tokens that appear valid cryptographically but lack corresponding on-premises interactive sessions. Privileged access reviews of local administrators, RDP sessions, and break-glass accounts on federation servers close another common gap.
Microsoft’s own hardening documentation also stresses high-fidelity logging and SIEM correlation with domain authentication events. Many organizations still run AD FS with default audit settings that leave DKM and certificate operations under-instrumented.
Immediate Hardening Checklist
- Inventory every AD FS farm, including disaster-recovery, staging, and legacy Extended Security Updates nodes.
- Confirm that only AD and AD FS administrators hold local admin rights; remove unnecessary accounts.
- Review DKM container ACLs and remove inherited or explicit rights that are not required by the AD FS service account and highly privileged groups.
- Enable and retain Directory Service Access auditing for the DKM path and contact objects that hold key material.
- Prefer group-managed service accounts and protect signing certificates; evaluate HSM storage where policy allows.
- Restrict interactive logon to AD FS servers; require jump hosts and endpoint detection.
- Minimize proxy-enabled endpoints to those required by current applications; disable unused trust protocols.
- Establish a tested process for rotating token-signing certificates and updating federation trusts in Entra ID and third-party applications.
- Hunt for historical DKM reads and certificate export events before assuming the environment is clean.
- Document a migration or reduction plan for remaining on-premises federation surface.
Strategic Implications
Golden SAML persists because hybrid identity still places cryptographic trust in servers that many organizations treat like ordinary application hosts. A local foothold that reaches DKM material or the AD FS service context can produce the same strategic outcome as a more glamorous zero-day: broad, MFA-resistant access to federated cloud resources.
The durable defenses are architectural as much as tactical. Reduce the number of systems that hold long-lived signing keys. Move authentication toward modern cloud-native flows where feasible. Enforce least privilege and continuous monitoring on the remaining AD FS estate. Treat token-signing material with the same rigor applied to domain controllers and KRBTGT.
Organizations that inventory their federation footprint, lock down DKM and certificate access, instrument the right audit events, and rehearse certificate rotation will close the most common paths. Those that continue to leave AD FS servers lightly managed will keep offering attackers a reliable second-stage path from on-premises compromise to cloud identity control. The technique is no longer new. The risk remains current.