AD FS Security Guide: Signing Keys, Lockout, Migration

Active Directory Federation Services holds a token-signing key that every federated application trusts, so whoever controls an AD FS server can sign in as anyone, without a password or MFA. That is the Golden SAML technique used in the SolarWinds-era intrusions, and it is why AD FS servers belong in the same tier as domain controllers. AD FS also sits on the internet edge through Web Application Proxy, where it absorbs password spraying aimed at Active Directory accounts. This guide covers how identity and trust work in an AD FS farm, which accounts and keys are privileged, how to log and detect abuse, the hardening baseline from Microsoft's guidance, and how to plan the move to Microsoft Entra ID that Microsoft now recommends. It is for identity engineers, Windows administrators and security teams that still run AD FS.

Key takeaways

The token-signing key is a Tier 0 credential. Anyone who extracts it can forge SAML tokens for every relying party, including Microsoft 365, so protect it with an HSM or tight server access and rotate it twice after any suspected compromise.
Treat AD FS servers like domain controllers. Microsoft recommends limiting administrators to AD and AD FS admins, a dedicated top-level OU, GPOs scoped only to AD FS, and admin workstations for anyone who manages them.
Turn on Extranet Smart Lockout. Run AdfsSmartLockoutLogOnly for 3 to 7 days, then AdfsSmartLockoutEnforce, with ExtranetLockoutThreshold below the AD lockout threshold so attackers cannot lock out AD accounts.
Close the endpoints that bypass lockout. Disable the WS-Trust windowstransport endpoints on the proxy and publish only the endpoints you need.
The safest AD FS is a decommissioned one. Microsoft's migration guidance favours password hash synchronisation or certificate-based authentication in Entra ID, with staged rollout and a documented rollback, followed by a clean decommission.

How identity and access work in AD FS

AD FS is a security token service. Users authenticate to it with Windows integrated authentication on the intranet or forms, certificate or MFA on the extranet, and AD FS issues a signed SAML, WS-Federation or OpenID Connect token to a relying party (an application such as Microsoft 365, Salesforce or an internal web app). The relying party trusts the token because it trusts the AD FS token-signing certificate. Claims rules on each relying party trust decide which attributes are issued and which users are allowed.

Component	Role	Security-relevant detail
Federation servers	Validate credentials against AD and issue tokens	Hold token-signing and token-decrypting private keys; Tier 0
Web Application Proxy (WAP)	Publishes AD FS endpoints to the internet from the DMZ	Authenticates to AD FS with a short-lived proxy trust certificate; revoke proxy trust if a WAP server is compromised
Configuration database (WID or SQL Server)	Stores relying party trusts, claims rules and settings	Write access equals the ability to add a malicious relying party or change claims rules
AD FS service account	Runs the adfssrv service	Has read access to the signing keys; Microsoft recommends a gMSA, otherwise a password over 25 characters
Certificate sharing container in AD	Holds the key material used to protect automatically generated certificates' private keys	Its DN is shown as CertificateSharingContainer in Get-AdfsProperties; read access to it is a Golden SAML path
Token-signing and token-decrypting certificates	Sign issued tokens and decrypt incoming ones	Self-signed certificates are generated automatically with roughly one-year validity when AutoCertificateRollover is on

Ports are simple and worth enforcing: users reach WAP on TCP 443 (and TCP 49443 only if certificate authentication is used), WAP reaches federation servers on 443, farm members sync configuration over HTTP 80 restricted to farm and WAP addresses, and Entra Connect uses 443, 80 for CRLs and WinRM 5985 when it manages the farm. For the protocol side see the SAML Security Guide.

Admin roles and privileged access

Local Administrators on federation servers: anyone in this group can read the signing keys through the service, so it should contain only AD FS administrators and Domain Admins. Microsoft lists reducing local admin membership on all AD FS servers as a core recommendation.
Domain Admins and anyone who controls the AD FS OU or GPOs: can take over AD FS servers. Place AD FS computer objects in a top-level OU with no other servers, and scope GPOs to that OU only, so a lower-tier GPO change cannot reach them. See the Tiered Administration and Enterprise Access Model Guide.
The AD FS service account: a gMSA removes a static password; if a user account is used, it must not be reused anywhere else. See the Group Managed Service Accounts (gMSA) Guide.
SQL Server administrators: where the configuration database is on SQL Server, the DBAs and the SQL service account can change relying parties and claims rules. Treat that SQL instance as Tier 0 or use WID.
Hybrid Identity and Global Administrators in Entra ID: can change federation settings for the tenant, including adding a federated domain with an attacker's certificate. Require phishing-resistant MFA and alert on federation configuration changes.
Help desk lockout resets: Reset-ADFSAccountLockout and Set-ADFSAccountActivity can be delegated through Just Enough Administration rather than by giving help desk staff admin rights on the farm.

Integrations, API tokens and service accounts

Token-signing and decrypting certificates

Know your rollover mode: with AutoCertificateRollover enabled, AD FS generates a new certificate CertificateGenerationThreshold days before expiry and promotes it CertificatePromotionThreshold days later. Microsoft advises planning certificate changes at least 60 days ahead so partners can consume the new key from federation metadata.
Partners that cannot read metadata: must be sent the new public key manually. Keep a register of these relying parties, because they cause most rollover outages and often drive teams to extend certificate lifetimes.
Entra ID federated domains: must be updated with the current token-signing certificate. A tenant with a second, unknown signing certificate on a federated domain is an indicator of compromise.
HSM protection: Microsoft supports installing the farm with HSM-backed signing and decrypting certificates (Install-AdfsFarm with SigningCertificateThumbprint and DecryptionCertificateThumbprint). An HSM stops key export, though an attacker with admin on a federation server can still request signatures while they hold access.
After compromise: rotate the token-signing certificate twice in quick succession, so the old key is no longer even the secondary, then re-establish trust with each relying party. The Golden SAML and Federation Trust Abuse Defence Guide covers the response in detail.

Relying parties, claims rules and MFA

Inventory relying party trusts: Get-AdfsRelyingPartyTrust lists every application; record owner, identifiers, signing requirements and the issuance authorisation rules. Remove unused trusts, which are both attack surface and migration blockers.
Claims rules are code: a permissive issuance rule can grant administrative roles to any user. Review changes and store exported rules in version control.
Do not let AD FS MFA claims bypass Entra MFA: set federatedIdpMfaBehavior to rejectMfaByFederatedIdp so Entra ID always performs its own MFA, unless you rely on a third-party MFA provider through AD FS.
Entra Connect: when it manages federation, its service accounts and server are also Tier 0. See the Microsoft Entra Connect and Cloud Sync Hardening Guide.

Logging and detection

Enable AD FS security auditing on every federation server: run auditpol.exe /set /subcategory:"Application Generated" /success:enable /failure:enable, enable success and failure audits in the federation service properties, and make sure the service account holds the Generate security audits right. Microsoft's hardening guidance recommends the highest logging level and SIEM correlation with AD and Entra sign-in logs. Set-AdfsProperties -AuditLevel Verbose logs every event per request; Basic, the default, logs no more than five.

Event	Log	Use
1200 Application token success	Security (AD FS Auditing)	Baseline of tokens issued per relying party; compare with Entra sign-ins to find tokens Entra received that AD FS never issued, the main Golden SAML signal
1201 Application token failure	Security	Misconfigured or probing relying parties
1202 and 1203 Credential validation success and failure	Security	Password spraying (many 1203 across users from few IPs), and success after many failures
1210 Extranet lockout	Security (ESL in log-only or enforce)	Accounts locked from unfamiliar locations
Admin log events	Applications and Services Logs\AD FS\Admin	Certificate rollover, service errors, configuration problems
Directory service access on the certificate sharing container	Security on DCs (with a SACL)	Reads of the container's key material by anything other than the AD FS service account
Entra ID audit log	Microsoft Entra	Changes to domain federation settings, new federated domains, new signing certificates

All events for one request share an Activity ID, which lets you trace a sign-in through WAP and federation servers. For the cloud side see the Entra ID Sign-In and Audit Log Detection Guide; for spraying patterns see the Password Spraying and Credential Stuffing Defence Guide.

Metrics

Tier 0 hygiene: number of local administrators on federation servers (target: only named AD FS admins).
Token reconciliation: share of Entra federated sign-ins that match an AD FS 1200 event (target 100%, investigate every gap).
Lockout protection: ESL in enforce mode on every farm, and count of AD account lockouts caused by extranet attempts (target near zero).
Relying party inventory: trusts with no 1200 events in 90 days, trending to zero through removal or migration.
Certificate health: days to token-signing expiry, and number of relying parties needing manual key updates.
Migration progress: percentage of users and applications authenticated by Entra ID rather than AD FS.

Hardening baseline

Patch first: keep federation and WAP servers on the current cumulative update and test in a staging farm. CISA added CVE-2026-56155, an AD FS elevation of privilege flaw, to the Known Exploited Vulnerabilities catalogue in July 2026; its KEV entry points to Microsoft's AD FS decommission guide as well as the update.
Isolate the servers: top-level OU, scoped GPOs, minimal local admins, host firewalls limited to the ports above, no browsing or email from the servers, and management only from admin workstations.
Enable Extranet Smart Lockout: Set-AdfsProperties -EnableExtranetLockout $true -ExtranetLockoutThreshold 15 -ExtranetObservationWindow (New-TimeSpan -Minutes 30) -ExtranetLockoutRequirePDC $false, with the threshold about half the AD lockout threshold. Run -ExtranetLockoutMode AdfsSmartLockoutLogOnly for 3 to 7 days, review 1203 and 1210 events, then switch to AdfsSmartLockoutEnforce and restart adfssrv on every node. Roll back by returning to log-only mode.
Reduce published endpoints: disable /adfs/services/trust/2005/windowstransport and /adfs/services/trust/13/windowstransport on the proxy (Set-AdfsEndpoint -TargetAddressPath ... -Proxy $false), and any other endpoints not on Microsoft's minimal list for your applications.
Enforce TLS 1.2: disable SSL 3.0, TLS 1.0 and TLS 1.1 on every farm server and WAP, enable SchUseStrongCrypto for .NET, and reboot each node. Microsoft notes that disabling TLS 1.0 can break older WAP to AD FS trusts, so test the proxy trust first.
Protect keys: use HSM-backed certificates where you can; otherwise restrict who can log on to federation servers and audit the certificate sharing container.
Require MFA on the extranet: through access control policies or, better, by moving the relying party to Entra ID with Conditional Access.
Back up the farm: use the AD FS Rapid Restore Tool and store backups as Tier 0 material, because they contain key material.

Migration to Entra ID

Option	When to choose it	Trade-off
Password hash synchronisation (PHS)	Default choice in Microsoft's guidance; removes the on-premises dependency for sign-in	Password hashes derived from AD are synchronised to Entra ID
Certificate-based authentication (CBA)	Smart card or certificate estates wanting phishing-resistant sign-in	Needs PKI and revocation checking in place
Pass-through authentication (PTA)	Only where regulation prohibits syncing password information	Agents on-premises become a dependency and a credential path
Keep AD FS	Relying parties that cannot move yet, or offline networks	Tier 0 server estate, certificate rollover and patching remain your responsibility

Document: export federation settings (Get-MgDomainFederationConfiguration) and the Microsoft 365 relying party trust, and take a Rapid Restore backup.
Pilot with staged rollout: enable PHS or CBA staged rollout for cloud-only pilot groups and test sign-in, SSO through Primary Refresh Tokens and MFA.
Convert domains: Update-MgDomain -DomainId <domain> -AuthenticationType Managed, one domain at a time, out of hours, allowing up to 60 minutes for the change to take effect. Roll back with New-MgDomainFederationConfiguration using the settings you documented.
Move applications: re-register SaaS relying parties as Entra enterprise applications and publish on-premises apps through Entra application proxy.
Decommission: after at least a week with no relying party traffic, remove load balancer and DNS entries, uninstall WAP then secondary and primary federation servers, delete SSL certificates, re-image the servers, delete the service account and clear the CertificateSharingContainer contents.

Common misconfigurations

AD FS managed as an ordinary member server: in the SolarWinds supply chain compromise, attackers with on-premises admin rights obtained the SAML token-signing certificate and forged tokens to reach cloud services without passwords or MFA.
Extranet lockout off or set above the AD threshold: spraying through WAP locks out AD accounts or, worse, finds valid passwords with no throttling.
Windowstransport endpoints published externally: they accept credentials outside the lockout logic.
No reconciliation between AD FS and the cloud: forged tokens look valid to Entra ID; only comparing them with AD FS issuance events reveals them.
Certificate rollover disabled to avoid outages: long-lived signing certificates with no rotation process, so a stolen key stays useful for years.
Abandoned relying parties and stalled migrations: a few legacy apps keep a whole Tier 0 farm alive with nobody owning it.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	MITRE ATT&CK
Token-signing key protection and rotation	SC-12, IA-5	PR.AA-01	T1606.002 SAML Tokens, T1552.004 Private Keys
Federation trust changes	AC-2, CM-6	PR.AA-05	T1484.002 Trust Modification, T1556.007 Hybrid Identity
Extranet lockout and MFA	AC-7, IA-2	PR.AA-03	T1110.003 Password Spraying
Server isolation and admin tiering	AC-6, SC-7	PR.AA-05, PR.PS-01	T1078.002 Domain Accounts
Patching	SI-2	PR.PS-02	T1068 Exploitation for Privilege Escalation
Auditing and reconciliation	AU-2, AU-6	DE.CM-03	Supports detection of all of the above

Practitioner checklist

List local administrators on every federation server and remove everyone who is not an AD FS or domain administrator.
Confirm AD FS servers sit in their own top-level OU with GPOs scoped only to them.
Run the AD FS service as a gMSA and restrict read access to the certificate sharing container.
Enable Extranet Smart Lockout, log-only then enforce, with a threshold below the AD lockout threshold.
Disable the windowstransport endpoints on the proxy and review every proxy-enabled endpoint.
Enable Verbose auditing and Application Generated auditing, forward to the SIEM and reconcile 1200 events with Entra federated sign-ins.
Alert on any change to Entra domain federation settings or new federated domains.
Document the token-signing rollover process and the relying parties that need manual key updates.
Patch federation and WAP servers within your KEV deadline.
Set a migration target date for moving users to PHS or CBA and applications to Entra ID.

AD FS Security Guide: Protecting Token-Signing Keys, Stopping Password Attacks and Planning Migration