Active Directory Federation Services (AD FS): Setup and Common Errors

AD FS lets your on-premises Active Directory issue security tokens so users can single sign-on into external services (Office 365 in hybrid setups without Entra Connect sync, SaaS apps supporting SAML/WS-Fed) without those services ever seeing an AD password directly. It has a reputation for being fiddly to set up, and the reputation is earned mostly because of certificate and SPN issues rather than the actual federation logic.

• AD FS needs its own SSL certificate matching the federation service name (e.g. sts.yourdomain.com). A self-signed cert will break external trust
• The federation service name is permanent once set. Plan the DNS name carefully before installing
• A Web Application Proxy (WAP) server is required to expose AD FS securely to external users
• Most “trust” errors trace back to a certificate that doesn’t match the SPN or has expired

Step 1: Install the AD FS role

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

Step 2: Configure the federation service with a proper certificate

Before running the configuration wizard, get a proper SSL certificate (from your internal CA or a public one) issued for the exact federation service name you intend to use. Run Install-AdfsFarm specifying this certificate’s thumbprint, the federation service name, and a service account. Using a self-signed or mismatched certificate here is the single biggest source of “the trust relationship failed” errors down the line.

Step 3: Add relying party trusts

Each external service that will accept AD FS tokens needs a relying party trust configured in the AD FS management console, along with claim rules defining what user attributes get sent (email, UPN, group membership). Test each new trust with a single pilot user before rolling it out broadly. Claim rule mistakes are easy to make and easy to fix in isolation, painful to untangle once many users are affected.

Common errors and their real causes

“An error occurred during an attempt to build the certificate chain” almost always means the certificate’s issuing CA isn’t trusted by the client or WAP server. “MSIS7042: The same client browser session has made X requests” points to a claims loop, usually a misconfigured relying party redirecting back to AD FS repeatedly. Event ID 364 on the AD FS server itself is the most useful troubleshooting starting point. It logs the specific SAML/WS-Fed error before it gets abstracted into a generic browser message.

For official guidance, see Microsoft’s Windows Server documentation.