AD FS

After configuration is complete, it is recommended to use AD FS testing tools (such as Test-AdfsClaimDescription or the AD FS logs in Event Viewer) to verify claim output.

In the AD FS Management console, adding a relying party trust is the first step in a SAML SSO connection, and the operation path is to right-click the "Relying Party Trusts" folder under the "AD FS" node and select "Add Relying Party Trust" to launch the wizard.

Importing a relying party trust from metadata automatically fills in endpoint, identifier, and certificate information, but you need to confirm that the imported identifier matches the value used in subsequent claim rules, otherwise tokens will be rejected.

The SAML assertion consumer service endpoint (ACS URL) must exactly match the receiving endpoint configured on the SP side, including protocol (usually https), domain, port, and path; any character difference will cause the assertion to fail to be delivered or to be rejected by the SP.

An SP may configure multiple ACS endpoints; AD FS uses the endpoint with index 0 by default, and this can be adjusted in the relying party trust properties if necessary.

AD FS claim rules are divided into two types: "Issuance Transform Rules" and "Issuance Authorization Rules".

The choice of Name ID format (such as unspecified, UPN, email address) directly affects how the service provider identifies the user; if the format the SP expects differs from what AD FS sends, login will fail.

The Claim Rule Language is a lightweight DSL built into AD FS that supports conditional judgments, querying attributes from Active Directory, and regular expression replacement of claim values, with the typical syntax being "condition => action", where the action can be issue, add, or issueStore.

The Claim Rule Language performs no compile-time checks; misspelled variable names, incorrect claim type URIs, or improper conditional expression syntax will cause rules to fail silently at runtime, i.e., the rules are saved but never trigger.

AD FS provides two metadata addresses: federation metadata (FederationMetadata.xml) and metadata for a specific relying party.

AD FS token signing certificates and token decryption certificates have a default validity period of one year, and before expiration AD FS automatically generates new certificates that coexist with the old ones for a period (called the certificate overlap period).

If the SP side refreshes metadata only after the old certificate expires, or if the metadata cache is not invalidated in time, AD FS signature verification will fail.

Token encryption is optional: when the SP requires encrypted assertions, the SP must provide an encryption certificate (public key) in its metadata, and AD FS encrypts the assertion with that public key before sending it, with the SP decrypting it using its own private key; if the SP metadata lacks an encryption certificate while AD FS is configured to "always encrypt assertions", the token will be rejected because it cannot be encrypted.

Misspelled endpoint URLs, mismatched Name ID formats, variable reference errors in claim rules, and unsynchronized certificates—these four types of problems cover most AD FS SAML SSO login failure troubleshooting scenarios.

Active Directory Federation Services (AD FS) is a federated identity service provided by Microsoft with Windows Server, allowing enterprises to expose internal Active Directory accounts to external SaaS applications via the SAML protocol.