How to Configure Active Directory Federation Services (AD FS 3.0) on Windows Server 2012 R2

Active Directory Federation Services 3.0 (AD FS) on Windows Server 2012 R2 provides Security Token Service (STS) functionality, enabling federated identity and single sign-on (SSO) across organizational boundaries and cloud applications. AD FS issues security tokens to authenticated users, which can be consumed by relying party applications without those applications needing to authenticate users themselves. Common use cases include SSO to Office 365, Salesforce, and custom web applications, as well as B2B federation between partner organizations. This guide covers deploying AD FS 3.0 as a standalone server and configuring relying party trusts for SSO.

Prerequisites

AD FS requires Windows Server 2012 R2 Standard or Datacenter. The server must be domain-joined and the domain functional level should be at Windows Server 2008 R2 or higher. A service account (standard domain account or Group Managed Service Account recommended) is needed for the AD FS service. An SSL certificate with the federation service name as the CN (e.g., sts.contoso.com) must be installed in the local computer certificate store before installation. The certificate must be trusted by all clients and relying parties — use a commercial CA or ensure your internal root CA certificate is deployed everywhere. A DNS record for the federation service name must be created. For high availability, deploy a farm of multiple AD FS servers behind a load balancer.

Installing the AD FS Role

# Install AD FS role and management tools
Install-WindowsFeature ADFS-Federation -IncludeManagementTools

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

Preparing the Service Account

Create a Group Managed Service Account (gMSA) for AD FS — this is the recommended approach as gMSA passwords are managed automatically:

# Create the KDS root key (required for gMSA - only once per forest)
# Wait 10 hours for replication, or force effective date in the past for lab:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)

# Create the gMSA for AD FS
New-ADServiceAccount -Name "svc-adfs" `
    -DNSHostName "sts.contoso.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "ADFS-Servers"  # Add ADFS server computer accounts

# Add the ADFS server to the group that can retrieve the gMSA password
New-ADGroup -Name "ADFS-Servers" -GroupScope DomainLocal
Add-ADGroupMember -Identity "ADFS-Servers" -Members "ADFS01$"

# Test gMSA account
Test-ADServiceAccount -Identity "svc-adfs"

Alternatively, create a standard domain service account:

New-ADUser -Name "svc-adfs" `
    -SamAccountName "svc-adfs" `
    -UserPrincipalName "[email protected]" `
    -AccountPassword (ConvertTo-SecureString "ADFSServicePass123!" -AsPlainText -Force) `
    -PasswordNeverExpires $true `
    -CannotChangePassword $true `
    -Enabled $true

Installing and Configuring the AD FS Farm

Configure the first AD FS server to create a new federation farm. The federation service name must match the CN of the SSL certificate:

# Get the thumbprint of the SSL certificate for sts.contoso.com
$CertThumbprint = (Get-ChildItem Cert:LocalMachineMy | 
    Where-Object {$_.Subject -like "*sts.contoso.com*"} |
    Select-Object -First 1).Thumbprint

# Install the first federation server in a new farm (using gMSA)
Install-AdfsFarm `
    -CertificateThumbprint $CertThumbprint `
    -FederationServiceName "sts.contoso.com" `
    -FederationServiceDisplayName "Contoso Sign-In" `
    -ServiceAccountCredential (Get-Credential "contososvc-adfs") `
    -OverwriteConfiguration

If deploying with SQL Server for larger farms (more than 5 servers), specify the SQL connection string:

# Install with SQL Server backend
Install-AdfsFarm `
    -CertificateThumbprint $CertThumbprint `
    -FederationServiceName "sts.contoso.com" `
    -FederationServiceDisplayName "Contoso Sign-In" `
    -ServiceAccountCredential (Get-Credential "contososvc-adfs") `
    -SQLConnectionString "Data Source=SqlServerMSSQLSERVER;Initial Catalog=AdfsConfiguration;Integrated Security=True"

Adding subsequent servers to the farm:

# Join additional server to existing farm
Add-AdfsFarmNode `
    -CertificateThumbprint $CertThumbprint `
    -ServiceAccountCredential (Get-Credential "contososvc-adfs") `
    -PrimaryComputerName "ADFS01.contoso.com"

Verifying the AD FS Installation

After installation, verify AD FS is running and accessible:

# Check AD FS service
Get-Service -Name ADFSSRV | Select-Object Status, StartType

# Check AD FS farm properties
Get-AdfsProperties | Select-Object HostName, Identifier, 
    CertificateSharePath, AutoCertificateRollover | Format-List

# Verify endpoint URLs are accessible
# Federation metadata URL (must be accessible for relying parties)
Invoke-WebRequest -Uri "https://sts.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml" -UseBasicParsing |
    Select-Object StatusCode

# Test OAuth token endpoint
Invoke-WebRequest -Uri "https://sts.contoso.com/adfs/oauth2/authorize" -UseBasicParsing |
    Select-Object StatusCode

Configuring a Relying Party Trust

A Relying Party Trust defines the relationship between AD FS and an application that accepts AD FS tokens. Add a trust for a custom web application:

# Add a relying party trust using the application's federation metadata URL
Add-AdfsRelyingPartyTrust `
    -Name "Corporate Intranet Portal" `
    -MetadataUrl "https://portal.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml" `
    -AutoUpdateEnabled $true `
    -Enabled $true

# Or add a trust manually (when the application doesn't publish federation metadata)
Add-AdfsRelyingPartyTrust `
    -Name "Custom Web App" `
    -Identifier "https://app.contoso.com/" `
    -WSFedEndpoint "https://app.contoso.com/login" `
    -SignatureAlgorithm http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 `
    -EncryptionCertificateRevocationCheck None `
    -Enabled $true

Configuring Claims Rules for Relying Party Trusts

Claims rules define what information is sent in the security token. Configure which claims from Active Directory to pass to the application:

# Create claim rules that pass AD attributes as claims
$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/upn",
             "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname",
             "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname",
             "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
             "http://schemas.microsoft.com/ws/2008/06/identity/claims/groups"),
    query = ";userPrincipalName,givenName,sn,mail,tokenGroups;{0}",
    param = c.Value);
"@

Set-AdfsRelyingPartyTrust -TargetName "Custom Web App" `
    -IssuanceTransformRules $ClaimRules

# Verify claim rules
(Get-AdfsRelyingPartyTrust -Name "Custom Web App").IssuanceTransformRules

Configuring Office 365 Federation

One of the most common AD FS use cases is federating with Office 365 for SSO. This requires Azure AD Connect (DirSync) and the Office 365 relying party trust:

# After running Azure AD Connect with AD FS option, the O365 RP trust is auto-created
# To add it manually (for reference):
$O365RPTrust = @{
    Name = "Microsoft Office 365 Identity Platform"
    Identifier = "urn:federation:MicrosoftOnline"
    IssuanceAuthorizationRules = "@RuleTemplate = `"AllowAllAuthzRule`""
    NotBeforeSkew = 2
    EncryptionCertificateRevocationCheck = "None"
    SignatureCertificateRevocationCheck = "None"
}
# Usually handled by Azure AD Connect wizard

# Verify O365 trust
Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform" |
    Select-Object Name, Enabled, Identifier

Configuring Authentication Policies

Configure which authentication methods are available and set MFA requirements:

# Configure primary authentication methods
Set-AdfsGlobalAuthenticationPolicy `
    -PrimaryIntranetAuthenticationProvider @("WindowsAuthentication") `
    -PrimaryExtranetAuthenticationProvider @("FormsAuthentication") `
    -WindowsIntegratedFallbackEnabled $true

# Require MFA for extranet access to a specific RP
$MFARule = @"
c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork",
    Value == "false"]
=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod",
    Value = "http://schemas.microsoft.com/claims/multipleauthn");
"@
Set-AdfsRelyingPartyTrust -TargetName "Custom Web App" `
    -AdditionalAuthenticationRules $MFARule

Monitoring AD FS

# Check AD FS token issuance events
# Event 299 = Successful token issuance
# Event 403 = Authentication failure
Get-WinEvent -LogName "AD FS/Admin" -MaxEvents 20 |
    Where-Object {$_.Id -in @(299,403,500)} |
    Select-Object TimeCreated, Id, Message | Format-List

# Check AD FS audit events (requires audit policy configuration)
Get-WinEvent -LogName "Security" | 
    Where-Object {$_.Message -like "*Active Directory Federation Services*"} |
    Select-Object TimeCreated, Id | Format-Table

Summary

AD FS 3.0 on Windows Server 2012 R2 provides a robust identity federation platform for SSO to internal and cloud applications. The deployment process involves: installing the ADFS-Federation role, preparing a gMSA service account, installing the farm with the SSL certificate, adding relying party trusts with appropriate claim rules, and configuring authentication policies. For high availability, deploy multiple AD FS servers behind a load balancer and use SQL Server for the configuration database. Regular monitoring of AD FS admin and security event logs ensures visibility into authentication success rates and failure patterns.

Links

Newsletter

Contact