How to Install Active Directory Federation Services (AD FS) on Windows Server 2025

Active Directory Federation Services (AD FS) extends Active Directory identity beyond the corporate network boundary, enabling Single Sign-On (SSO) for web applications and cloud services that span organisational trust boundaries. Rather than creating separate user accounts in each application or cloud tenant, AD FS issues security tokens — using SAML 2.0 or WS-Federation protocols — that applications can trust because they are signed by your organisation’s federation server. Windows Server 2025 ships with AD FS 2019-generation capabilities including enhanced security defaults, improved diagnostics, and tighter integration with Microsoft Entra ID (formerly Azure AD). This tutorial covers every step from SSL certificate preparation through configuring a relying party trust for a SAML application, with practical PowerShell commands throughout.

Prerequisites

A domain-joined Windows Server 2025 member server dedicated to AD FS. Do not install AD FS on a domain controller.
A valid SSL certificate for the federation service name (e.g., sts.corp.local or sts.corp.com). This can be issued by your AD CS Enterprise CA or a public CA. The certificate must include the federation service FQDN as the Subject or a SAN entry.
A group Managed Service Account (gMSA) for the AD FS service — strongly preferred over a standard service account. Requires the AD KDS Root Key to be present in the domain (Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)).
DNS A record for the federation service name pointing to the AD FS server’s IP address.
Domain Admin credentials and Enterprise Admin rights for schema/configuration partition writes.
A Windows Internal Database (WID) or SQL Server instance for the AD FS configuration database. WID is recommended for farms with fewer than 5 nodes.

Step 1: Install the AD FS Role

# Install the AD FS role (management tools included)
Install-WindowsFeature ADFS-Federation -IncludeManagementTools

# Verify installation
Get-WindowsFeature ADFS-Federation | Select-Object Name, InstallState, DisplayName

# Also install .NET Framework 4.8 if not already present (required by AD FS)
Install-WindowsFeature NET-Framework-45-Core, NET-Framework-45-ASPNET

Step 2: Prepare the SSL Certificate

AD FS requires an SSL certificate bound to the federation service name. If using an AD CS-issued certificate, request it before proceeding:

# Request a certificate for the federation service FQDN
$certReq = Get-Certificate `
    -Template "WebServer" `
    -DnsName "sts.corp.local","enterpriseregistration.corp.local" `
    -CertStoreLocation "Cert:LocalMachineMy" `
    -SubjectName "CN=sts.corp.local"

# Retrieve the thumbprint of the certificate (needed for Install-AdfsFarm)
$thumbprint = $certReq.Certificate.Thumbprint
Write-Host "Certificate thumbprint: $thumbprint"

# Verify the certificate is in the LocalMachineMy store
Get-ChildItem Cert:LocalMachineMy | 
    Where-Object { $_.Subject -match "sts.corp.local" } |
    Select-Object Subject, Thumbprint, NotBefore, NotAfter

Step 3: Create a Group Managed Service Account

# Ensure KDS Root Key exists (run on DC — only needed once per domain)
# Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
# The -10 hours makes it immediately usable (production: use -EffectiveImmediately on WS2016+)

Add-KdsRootKey -EffectiveImmediately

# Create the gMSA for the AD FS service
New-ADServiceAccount `
    -Name "svc-adfs" `
    -DNSHostName "svc-adfs.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "ADFS01$"  # Computer account of the AD FS server

# Verify the gMSA is accessible from the AD FS server
Test-ADServiceAccount -Identity "svc-adfs"

Step 4: Configure the AD FS Farm

Run Install-AdfsFarm to configure AD FS. This creates the farm’s first node, initialises the WID configuration database, and registers the federation service in Active Directory:

# Install the first AD FS farm node using a gMSA
Install-AdfsFarm `
    -CertificateThumbprint $thumbprint `
    -FederationServiceName "sts.corp.local" `
    -FederationServiceDisplayName "Corp Identity Federation" `
    -GroupServiceAccountIdentifier "CORPsvc-adfs$" `
    -OverwriteConfiguration

# --- Alternative: use a standard service account (less preferred) ---
# $svcCred = Get-Credential -UserName "CORPsvc-adfs" -Message "AD FS service account"
# Install-AdfsFarm `
#     -CertificateThumbprint $thumbprint `
#     -FederationServiceName "sts.corp.local" `
#     -FederationServiceDisplayName "Corp Identity Federation" `
#     -ServiceAccountCredential $svcCred

# Verify the AD FS service is running
Get-Service adfssrv | Select-Object Name, Status, StartType

# Retrieve basic federation service information
Get-AdfsProperties | Select-Object HostName, HttpsPort, FederationServiceName

Step 5: Configure a Relying Party Trust for a SAML Application

A Relying Party Trust (RPT) defines a relationship between AD FS and an application (the relying party) that will accept security tokens. Most modern SaaS and on-premises applications support SAML 2.0:

# Add a relying party trust from a SAML metadata URL (preferred when available)
Add-AdfsRelyingPartyTrust `
    -Name "CorpHR-SAML-App" `
    -MetadataURL "https://hr.corp.com/saml/metadata" `
    -MonitoringEnabled $true `
    -AutoUpdateEnabled $true `
    -Enabled $true

# --- Alternative: manual configuration without metadata URL ---
Add-AdfsRelyingPartyTrust `
    -Name "CorpHR-SAML-App" `
    -Identifier "https://hr.corp.com/saml" `
    -SamlEndpoint (New-AdfsSamlEndpoint `
        -Binding POST `
        -Protocol SAMLAssertionConsumer `
        -Uri "https://hr.corp.com/saml/acs") `
    -IsEnabled $true `
    -EncryptionCertificate (Get-ChildItem Cert:LocalMachineMy | 
        Where-Object { $_.Subject -match "hr.corp.com" } | 
        Select-Object -First 1) `
    -AutoUpdateEnabled $false

# Verify the trust was created
Get-AdfsRelyingPartyTrust -Name "CorpHR-SAML-App" | 
    Select-Object Name, Identifier, Enabled, SamlEndpoints

Step 6: Configure Claim Rules

Claim rules transform Active Directory attributes into SAML assertions that the relying party can consume. Most applications need at minimum the user’s UPN or email address as the NameID:

# Define claim rules as a rule set string
$claimRules = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Send LDAP Attributes as Claims"
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/groups"),
   query = ";mail,givenName,sn,tokenGroups;{0}", param = c.Value);
"@

# Apply the claim rules to the relying party trust
Set-AdfsRelyingPartyTrust `
    -TargetName "CorpHR-SAML-App" `
    -IssuanceTransformRulesFile $null `
    -IssuanceTransformRules $claimRules

# Add an issuance authorisation rule (who is allowed to authenticate)
$authRule = '@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");'

Set-AdfsRelyingPartyTrust `
    -TargetName "CorpHR-SAML-App" `
    -IssuanceAuthorizationRules $authRule

Step 7: Install Web Application Proxy (Optional but Recommended)

The Web Application Proxy (WAP) role acts as a reverse proxy, publishing the AD FS federation endpoint to the internet without exposing the AD FS server directly. WAP is installed on a separate server in the DMZ:

# On the WAP server (NOT the AD FS server):
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools

# Retrieve the AD FS SSL certificate thumbprint to use on WAP
# (the same cert must be in the WAP server's LocalMachineMy store)

# Configure WAP to proxy AD FS
$federationCred = Get-Credential -Message "Domain Admin credentials for AD FS join"

Install-WebApplicationProxy `
    -FederationServiceTrustCredential $federationCred `
    -CertificateThumbprint $thumbprint `
    -FederationServiceName "sts.corp.local"

# Publish the AD FS federation service through WAP
Add-WebApplicationProxyApplication `
    -Name "AD FS Federation Service" `
    -ExternalPreAuthentication PassThrough `
    -ExternalUrl "https://sts.corp.com/adfs/ls" `
    -BackendServerUrl "https://sts.corp.local/adfs/ls"

Step 8: Test Federation with the AD FS Diagnostic Tool

# Test AD FS endpoint reachability
Invoke-WebRequest -Uri "https://sts.corp.local/adfs/ls/IdpInitiatedSignon.aspx" `
    -UseDefaultCredentials | Select-Object StatusCode

# Check AD FS event log for token issuance events (Event IDs 299, 500, 1200)
Get-WinEvent -LogName "AD FS/Admin" -MaxEvents 50 |
    Where-Object { $_.Id -in @(299, 500, 1200, 325, 364) } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-Table -AutoSize -Wrap

# Verify all AD FS proxies are registered (run on AD FS server)
Get-AdfsProxyProperties

# Check relying party trust token issuance statistics
Get-AdfsRelyingPartyTrust | 
    Select-Object Name, Enabled, LastUpdateTime |
    Format-Table -AutoSize

Conclusion

Active Directory Federation Services on Windows Server 2025 bridges the gap between on-premises Active Directory identities and the modern web of SAML-based SaaS applications, cloud platforms, and partner portals. By following this tutorial — installing the AD FS role, binding a valid SSL certificate, configuring the farm with a group Managed Service Account, defining relying party trusts with appropriate claim rules, and optionally deploying Web Application Proxy — you establish a production-grade federation service that delivers seamless Single Sign-On while keeping your AD identities as the authoritative source of truth. Pair AD FS with Entra ID Connect for a hybrid identity model that extends this federation capability all the way to Microsoft 365 and Azure workloads.

Links

Newsletter

Contact