How to Set Up Active Directory Federation Services (AD FS) on Windows Server 2019

Active Directory Federation Services (AD FS) provides Single Sign-On (SSO) capabilities, enabling users to authenticate once with their corporate credentials and access applications hosted in cloud services (Microsoft 365, Salesforce, Workday) or partner organizations without re-entering credentials. AD FS implements the WS-Federation, WS-Trust, SAML 2.0, and OAuth 2.0 / OpenID Connect protocols. Windows Server 2019 AD FS 4.0 includes improvements for modern authentication, extranet lockout, and integration with Azure AD.

Prerequisites

Before installing AD FS, ensure the following are in place: a domain-joined server with at least 2 GB RAM and 100 GB disk space, a valid SSL/TLS certificate with a Subject Alternative Name (SAN) matching the AD FS service name (e.g., fs.corp.example.com), a dedicated service account in Active Directory (or use Group Managed Service Account – gMSA which is recommended), and DNS records for the AD FS service name pointing to the AD FS server or load balancer VIP.

# Create a Group Managed Service Account for AD FS
# First, ensure the KDS Root Key exists (one-time setup per forest)
Add-KdsRootKey -EffectiveImmediately

# Wait 10 hours for the key to replicate, or for lab/testing use:
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

# Create the gMSA
New-ADServiceAccount `
    -Name "svc-adfs" `
    -DNSHostName "fs.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "ADFS-Servers" `
    -ServicePrincipalNames @("host/fs.corp.example.com","http/fs.corp.example.com")

# Grant the ADFS server access to use the gMSA
$adfsServer = Get-ADComputer -Identity "ADFS01"
$group = Get-ADGroup -Identity "ADFS-Servers"
Add-ADGroupMember -Identity $group -Members $adfsServer

Obtaining a Certificate for AD FS

AD FS requires a server certificate for its SSL endpoint and for token signing/decryption. Use an enterprise CA to issue the certificate:

# Request a certificate with SAN for the AD FS service name
$cert = Get-Certificate `
    -Template "WebServer-2Year" `
    -SubjectName "CN=fs.corp.example.com" `
    -DnsName "fs.corp.example.com","enterpriseregistration.corp.example.com","certauth.fs.corp.example.com" `
    -CertStoreLocation "Cert:LocalMachineMy"

$cert.Certificate.Thumbprint

Installing the AD FS Role

# Install AD FS role
Install-WindowsFeature -Name ADFS-Federation -IncludeManagementTools

# Verify
Get-WindowsFeature -Name ADFS*

Configuring the AD FS Farm (First Server)

Configure the first AD FS server to create the federation farm. The farm configuration is stored in a WID (Windows Internal Database) for small deployments or a SQL Server database for large, high-availability deployments:

Import-Module ADFS

# Get the SSL certificate
$cert = Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like "*fs.corp.example.com*"}

# Install AD FS farm using WID (Windows Internal Database)
Install-AdfsFarm `
    -CertificateThumbprint $cert.Thumbprint `
    -FederationServiceDisplayName "Example Corp Federation Service" `
    -FederationServiceName "fs.corp.example.com" `
    -GroupServiceAccountIdentifier "CORPsvc-adfs$" `
    -OverwriteConfiguration

# For SQL Server backend (recommended for large deployments):
Install-AdfsFarm `
    -CertificateThumbprint $cert.Thumbprint `
    -FederationServiceDisplayName "Example Corp Federation Service" `
    -FederationServiceName "fs.corp.example.com" `
    -GroupServiceAccountIdentifier "CORPsvc-adfs$" `
    -SQLConnectionString "Data Source=sql01.corp.example.com;Initial Catalog=AdfsConfiguration;Integrated Security=True" `
    -OverwriteConfiguration

# Verify the farm is configured
Get-AdfsFarmInformation

Adding a Second AD FS Server to the Farm

For high availability, add additional servers to the AD FS farm. All servers in the farm share the same configuration via WID sync or SQL Server replication:

# On the second AD FS server
Install-WindowsFeature -Name ADFS-Federation -IncludeManagementTools

$cert = Get-ChildItem Cert:LocalMachineMy | Where-Object {$_.Subject -like "*fs.corp.example.com*"}

# Join the existing farm
Add-AdfsFarmNode `
    -CertificateThumbprint $cert.Thumbprint `
    -GroupServiceAccountIdentifier "CORPsvc-adfs$" `
    -PrimaryComputerName "adfs01.corp.example.com" `
    -PrimaryComputerPort 80

# Verify the farm node
Get-AdfsFarmInformation

Configuring a Relying Party Trust for Microsoft 365

A Relying Party Trust defines the application (Office 365, Salesforce, etc.) that AD FS issues tokens for. For Microsoft 365, use Azure AD Connect to automatically configure federation:

# Add a Relying Party Trust using federation metadata (for apps that publish metadata)
Add-AdfsRelyingPartyTrust `
    -Name "Microsoft Office 365 Identity Platform" `
    -MetadataURL "https://nexus.microsoftonline-p.com/federationmetadata/2007-06/federationmetadata.xml" `
    -AutoUpdateEnabled $true `
    -MonitoringEnabled $true `
    -IssuanceAuthorizationRulesFile "C:ADFSO365-AuthRules.txt"

# List all Relying Party Trusts
Get-AdfsRelyingPartyTrust | Select-Object Name, Enabled, Identifier | Format-Table

# Create issuance transform rules for Microsoft 365
$rules = @"
@RuleName = "Pass through UPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(claim = c);

@RuleName = "Pass through ImmutableID"
c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"]
=> issue(claim = c);
"@

Set-AdfsRelyingPartyTrust `
    -TargetName "Microsoft Office 365 Identity Platform" `
    -IssuanceTransformRules $rules

Configuring Claims Provider Trusts

Claims Provider Trusts define the identity source for authentication. Active Directory is the default claims provider. Configure additional ones for partner federation:

# View the default Active Directory claims provider
Get-AdfsClaimsProviderTrust | Select-Object Name, Enabled, Identifier

# Add a partner organization as a claims provider (accepts SAML tokens from them)
Add-AdfsClaimsProviderTrust `
    -Name "Partner Corp" `
    -MetadataURL "https://fs.partner.com/FederationMetadata/2007-06/FederationMetadata.xml" `
    -AutoUpdateEnabled $true `
    -MonitoringEnabled $true

Configuring Extranet Lockout Protection

AD FS 4.0 (Windows Server 2019) includes Smart Extranet Lockout, which tracks authentication failures from the extranet (external) separately from the intranet, protecting AD accounts from being locked out by external brute-force attacks:

# Enable Smart Extranet Lockout
Set-AdfsProperties `
    -EnableExtranetLockout $true `
    -ExtranetLockoutThreshold 10 `
    -ExtranetObservationWindow (New-TimeSpan -Minutes 30) `
    -ExtranetLockoutRequirePDC $false `
    -EnableExtranetSmartLockout $true `
    -ExtranetSmartLockoutThreshold 10

# View current extranet lockout settings
Get-AdfsProperties | Select-Object EnableExtranetLockout, ExtranetLockoutThreshold, EnableExtranetSmartLockout

# Reset a user locked out by extranet lockout (does not affect AD lockout)
Reset-AdfsAccountLockout -UserPrincipalName [email protected]

Monitoring AD FS

# Check AD FS service health
Get-AdfsSyncProperties
Get-AdfsProperties | Select-Object FederationServiceName, FederationServiceIdentifier

# View AD FS diagnostic logs
Get-WinEvent -LogName "AD FS/Admin" | Select-Object -First 20 | Select-Object TimeCreated, LevelDisplayName, Message

# Enable verbose tracing
Set-AdfsProperties -LogLevel @("FailureAudits","SuccessAudits","Errors","Warnings","Information","Verbose")

# Check token issuance statistics
Get-AdfsRelyingPartyTrust | ForEach-Object {
    [PSCustomObject]@{
        Name = $_.Name
        IsEnabled = $_.Enabled
        LastUpdateTime = $_.LastMonitoredTime
    }
}

# Test AD FS endpoint availability
Invoke-WebRequest -Uri "https://fs.corp.example.com/federationmetadata/2007-06/federationmetadata.xml" -UseBasicParsing

AD FS is a complex but essential component for organizations using cloud services or engaging in cross-organization collaboration. For new deployments, consider whether Azure AD Pass-Through Authentication or Password Hash Sync with Azure AD Connect might meet your requirements with lower operational overhead before deploying a full AD FS infrastructure, which requires high availability, certificate management, and proxy server configuration.