Understanding SAML 2.0 and Federated Identity

Security Assertion Markup Language 2.0 (SAML 2.0) is an open XML-based standard for exchanging authentication and authorization data between an Identity Provider (IdP) and a Service Provider (SP). It is the dominant protocol for enterprise Single Sign-On (SSO) integration with web applications such as Salesforce, ServiceNow, AWS, and hundreds of others. When a user clicks Sign In on a SAML-enabled application, an XML-encoded assertion is generated, digitally signed by the IdP, and passed to the SP to establish a session without the user entering credentials again.

There are two SAML flow patterns. In SP-initiated SSO, the user goes directly to the application URL, the SP redirects them to the IdP for authentication, and after successful login the IdP posts a SAML Response back to the SP’s Assertion Consumer Service (ACS) endpoint. In IdP-initiated SSO, the user starts at the IdP portal (such as the AD FS application portal), selects an application, and is sent directly to the SP with a pre-generated SAML assertion. SP-initiated is more common in practice because users typically navigate to apps directly.

On Windows Server 2022, Microsoft’s Active Directory Federation Services (AD FS) is the built-in identity provider for SAML 2.0 federation. AD FS integrates with your existing Active Directory infrastructure and issues SAML assertions signed with your SSL/TLS certificate. This guide covers full AD FS deployment for SAML SSO, relying party trust configuration, claims rules, external access via Web Application Proxy, and monitoring.

AD FS Role Overview and Prerequisites

AD FS runs as a Windows Server role. It consists of the Federation Service itself (which issues tokens) and, optionally, the Web Application Proxy (WAP) role installed on a separate DMZ server to expose AD FS to external users without placing the federation server in the DMZ. The AD FS server must be a domain member. WAP servers must NOT be domain members — they sit in the DMZ and communicate with AD FS over HTTPS on port 443.

Requirements for the AD FS server:

– Windows Server 2022 (Standard or Datacenter), domain-joined

– An SSL/TLS certificate with the federation service name as the subject (e.g., adfs.yourdomain.com) — this must be issued by a CA trusted by all clients and service providers

– A DNS entry pointing the federation service name to the AD FS server IP

– A dedicated service account in Active Directory (or Group Managed Service Account — gMSA is recommended)

– SQL Server or Windows Internal Database (WID) for the AD FS configuration database — WID is sufficient for up to 5 federation servers

Create a gMSA for AD FS:

New-ADServiceAccount -Name "svc-adfs" -DNSHostName "adfs.yourdomain.com" -PrincipalsAllowedToRetrieveManagedPassword "Domain Computers" -Enabled $true

Installing the AD FS Role

Install the AD FS role on your designated Windows Server 2022 federation server:

Install-WindowsFeature ADFS-Federation -IncludeManagementTools

After installation, open Server Manager. You will see a post-deployment configuration task: Configure the federation service on this server. Click it to launch the AD FS Configuration Wizard. Alternatively, run it from PowerShell:

Import-Module ADFS

Install-AdfsFarm `
    -CertificateThumbprint "THUMBPRINT_OF_YOUR_SSL_CERT" `
    -FederationServiceDisplayName "Contoso Federation Service" `
    -FederationServiceName "adfs.yourdomain.com" `
    -GroupServiceAccountIdentifier "YOURDOMAINsvc-adfs$" `
    -OverwriteConfiguration

Replace THUMBPRINT_OF_YOUR_SSL_CERT with the actual thumbprint of your SSL certificate (visible in certlm.msc). After this command completes, the AD FS service starts and the federation metadata is available at:

https://adfs.yourdomain.com/FederationMetadata/2007-06/FederationMetadata.xml

Verify the service is running:

Get-Service adfssrv | Select-Object Status, StartType

SSL Certificate Requirements for AD FS

AD FS requires a certificate with the Subject Alternative Name (SAN) containing:

– adfs.yourdomain.com (the federation service name)

– enterpriseregistration.yourdomain.com (for Workplace Join / device registration)

The certificate must be trusted by all browsers and clients that will use SSO. An internal PKI certificate works for internal clients, but external users accessing via WAP need a publicly trusted certificate from a commercial CA.

To check the current AD FS SSL binding:

Get-AdfsSslCertificate

To replace the SSL certificate:

Set-AdfsSslCertificate -Thumbprint "NEW_CERT_THUMBPRINT"

The token-signing and token-decrypting certificates are self-signed by AD FS automatically and rotate annually. Do not replace these unless required by a specific SP that cannot handle automatic rollover.

Configuring a Relying Party Trust

A Relying Party Trust (RPT) is the AD FS configuration object representing a SAML service provider. Each application that accepts SAML assertions from your AD FS gets its own RPT. You can add one from federation metadata (if the SP publishes a metadata URL) or manually.

To add an RPT from federation metadata:

Add-AdfsRelyingPartyTrust `
    -Name "Salesforce" `
    -MetadataURL "https://yourdomain.my.salesforce.com/.well-known/samlidp/metadata" `
    -AutoUpdateEnabled $true `
    -MonitoringEnabled $true `
    -Enabled $true

For a manual SAML 2.0 RPT where you have the SP’s metadata XML file:

Add-AdfsRelyingPartyTrust `
    -Name "ServiceNow" `
    -MetadataFile "C:adfsservicenow-metadata.xml" `
    -Enabled $true

For a fully manual configuration without metadata:

Add-AdfsRelyingPartyTrust `
    -Name "MyApp" `
    -Identifier "https://myapp.yourdomain.com" `
    -SamlEndpoint (New-AdfsSamlEndpoint -Protocol SAMLAssertionConsumer -Uri "https://myapp.yourdomain.com/saml/consume" -Binding POST) `
    -IssuanceAuthorizationRules "@RuleTemplate = `"AllowAllAuthzRule`"`n=> issue(Type = `"http://schemas.microsoft.com/authorization/claims/permit`", Value = `"true`");" `
    -Enabled $true

Configuring Claim Rules

Claims are the attributes AD FS includes in the SAML assertion — they tell the SP who the user is and what permissions they have. Claim rules define how attributes from Active Directory are transformed into claims. There are two categories: Issuance Transform Rules (which map AD attributes to outgoing claims) and Issuance Authorization Rules (which control who is allowed to receive a token for an RP).

To issue the user’s UPN as the NameID claim (required by most SPs):

$rule = @"
@RuleTemplate = "MapClaims"
@RuleName = "Send UPN as NameID"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
   Issuer = c.Issuer,
   OriginalIssuer = c.OriginalIssuer,
   Value = c.Value,
   ValueType = c.ValueType,
   Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");
"@

Set-AdfsRelyingPartyTrust -TargetName "Salesforce" -IssuanceTransformRules $rule

To send email, display name, and department as additional attributes:

$rules = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Send AD Attributes"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory",
   types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
            "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
            "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
            "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"),
   query = ";mail,givenName,sn,sAMAccountName;{0}", param = c.Value);
"@

Set-AdfsRelyingPartyTrust -TargetName "Salesforce" -IssuanceTransformRules $rules

SAML Token Signing Certificate Management

The token-signing certificate is what AD FS uses to digitally sign SAML assertions. Service providers import this certificate’s public key to verify the signature. AD FS generates self-signed token-signing certificates and by default rotates them 20 days before expiry.

To view current token-signing certificates:

Get-AdfsCertificate -CertificateType Token-Signing

When a new certificate is added as secondary and before the primary rolls over, you must update the SP’s trusted certificate before the rollover date. For SPs using metadata, if AutoUpdateEnabled is set on the RPT, they will pull the new certificate automatically from the federation metadata XML. For SPs with manual certificate configuration, you must export and re-import the certificate.

Export the primary token-signing certificate:

$cert = Get-AdfsCertificate -CertificateType Token-Signing | Where-Object { $_.IsPrimary -eq $true }
Export-Certificate -Cert $cert.Certificate -FilePath "C:adfstoken-signing.cer"

Installing and Configuring Web Application Proxy

The Web Application Proxy (WAP) role allows external users to access AD FS (and other internal web applications) without a VPN. WAP acts as a reverse proxy, forwarding authentication requests to the AD FS server inside the corporate network. WAP must be installed on a server in the DMZ that has network access to the AD FS server on port 443.

Install the WAP role on the DMZ server (not domain-joined):

Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

Configure WAP to connect to your AD FS farm:

Install-WebApplicationProxy `
    -CertificateThumbprint "THUMBPRINT_OF_ADFS_SSL_CERT" `
    -FederationServiceName "adfs.yourdomain.com" `
    -FederationServiceTrustCredential (Get-Credential)

Provide AD FS administrator credentials when prompted. After configuration, publish the AD FS endpoint through WAP:

Add-WebApplicationProxyApplication `
    -BackendServerURL "https://adfs.yourdomain.com/" `
    -ExternalCertificateThumbprint "THUMBPRINT_OF_ADFS_SSL_CERT" `
    -ExternalURL "https://adfs.yourdomain.com/" `
    -Name "AD FS" `
    -ExternalPreAuthentication PassThrough

With PassThrough pre-authentication, WAP forwards the request to AD FS without pre-authenticating. For applications behind WAP (non-AD FS), you can use ADFS pre-authentication to require users to authenticate at AD FS before WAP forwards the request to the backend.

AD FS with Azure AD as Federation Provider

When Azure AD is configured to use AD FS as a federated identity provider via Azure AD Connect, users whose UPN matches a federated domain are redirected from Azure AD to your AD FS server for authentication. This gives your on-premises AD FS complete control over the authentication experience and policies for those users.

To configure this, run Azure AD Connect and select Federation with AD FS as the sign-in method. The wizard will configure the relying party trust between Azure AD and your AD FS, including all required claim rules. To verify the federation trust from AD FS’s perspective:

Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform"

To check federation from Azure AD’s perspective using the MSOnline module:

Get-MsolDomainFederationSettings -DomainName "yourdomain.com"

Monitoring AD FS with Event Logs

AD FS writes detailed audit events to the Windows Security event log and the AD FS application event log. The most important event IDs for SAML SSO troubleshooting are:

Event ID 342 — An error occurred when validating the SAML authentication request. This often indicates a mismatch between the SP’s ACS URL configured in AD FS and the actual URL the SP is sending. Check the Relying Party Identifier and ACS endpoint.

Event ID 403 — The Federation Service could not authorize token issuance. This occurs when the user fails the Issuance Authorization Rule for the relying party — for example, if only specific AD groups are permitted.

Enable AD FS auditing to capture full authentication events:

Set-AdfsProperties -AuditLevel Verbose
auditpol /set /subcategory:"Application Generated" /success:enable /failure:enable

Query recent AD FS errors from the event log:

Get-WinEvent -LogName "AD FS/Admin" | Where-Object { $_.LevelDisplayName -eq "Error" } | Select-Object TimeCreated, Message -First 20

To trace a specific user’s authentication attempt, filter by their username in the Security log (Event IDs 1200 and 1202 for successful tokens, 1201 for failed issuance):

Get-WinEvent -LogName Security | Where-Object { $_.Message -like "*[email protected]*" } | Select-Object TimeCreated, Id, Message -First 10

Testing SAML SSO End to End

After configuring a relying party trust and claim rules, test SP-initiated SSO by navigating to the application login page and using its SAML login option. The browser should redirect to your AD FS sign-in page at https://adfs.yourdomain.com/adfs/ls/. After authenticating, AD FS redirects to the SP’s ACS endpoint with a signed SAML response.

For programmatic testing and debugging, use the AD FS diagnostic page available at:

https://adfs.yourdomain.com/adfs/ls/idpinitiatedsignon.htm

You can also use browser developer tools or a browser extension like SAML Tracer to capture and decode the SAML request and response XML to verify assertion attributes, signature validity, and NameID format.

For automated health checks from PowerShell:

Test-AdfsServerHealth -OperationalLog | Select-Object Name, Result, Detail

This cmdlet checks SSL certificate validity, service connectivity, endpoint accessibility, and token-signing certificate status, returning a pass/fail result for each check.

Summary

Active Directory Federation Services on Windows Server 2022 provides a robust, enterprise-grade SAML 2.0 identity provider that integrates tightly with your existing Active Directory infrastructure. By deploying AD FS with a properly issued SSL certificate, configuring relying party trusts with appropriate claim rules, publishing via Web Application Proxy for external access, and monitoring event logs for IDs 342 and 403, you can deliver seamless SSO to hundreds of cloud and on-premises applications while maintaining centralized identity control. When combined with Azure AD Connect federation, AD FS also becomes the authentication authority for your Microsoft 365 and Azure environment.