Securing Microsoft Active Directory Federation Server (ADFS)

Many organizations are moving to the cloud and this often requires some level of federation. Federation, put simply, extends authentication from one system (or organization) to another.

Gerald Steere (@Darkpawh) and I spoke about cloud security at DEF CON in July 2017.
Presentation slides and video are here: “Hacking the Cloud

One of the key items we covered was protecting Federation Servers, specifically  Microsoft Active Directory Federation Servers (ADFS).

Microsoft is currently updating guidance for securing ADFS.
This post describes key ADFS concepts and a short-list of security recommendations on how to properly protect ADFS.

Federation Overview

The federation server typically lives on the internal network with a proxy server in the DMZ. There are certificates installed on the Federation server.

ADFS uses the following certificates:

  • Service communication
  • Token-decrypting
  • Token-signing

ADFS terminology also includes:

  • Relying party trusts: cloud services and applications
  • Claim rules: determine what type of access and from where access is allowed.

Key Federation Points:

  • Federation: trust between organizations leveraging PKI (certificates matter)
  • Cloud SSO often leverages temporary or persistent browser cookies (cookies provide access)
  • Several protocols may be supported, though typically SAML. (protocols and versions matter)
  • Federation server (or proxy) is on public internet via port 443 (HTTPS).

Conceptual federation authentication flow

In the above graphic:

  • The user goes to website: and clicks Logon.
  • The user’s browser recognizes federation config and ping the web app’s federation logon page.
  • The user gets bounced to the registered federation server in the organization which either requests authentication, or uses existing user auth (AD Kerberos, etc). User may be prompted for multifactor authentication.
  • The federation server provides the user with a token for the web app to which the user wants to connect.
  • The user goes back to the web app’s authentication page and since the user has a token, the user is allowed access based on claims in the token.


Key Federation Authentication Items:

  • Federation is effectively a Cloud version of Kerberos (though there are key differences).
  • Own the Federation server, own organizational cloud services.
  • Token & Signing certificates are very similar to the KRBTGT account since they are both used to sign tokens proving authentication (think Golden Tickets).
  • Steal federation certificates to forge/spoof access tokens.

Underscoring the point Gerald & I made at DEFCON in 2017, CyberArk released “GoldenSAML” tools enabling someone with the federation server signing certificate to forge SAML tokens saying they are any user they wish. This capability means that Federation servers need to be protected at the highest level, along with Domain Controllers.

Note that while the CyberArk post states that GoldenSAML is “newly discovered”, this is incorrect. Anyone who has worked with Federation understands that ownership of the federation certificates means control of the authentication, much like ownership of PKI CA certificates enables creation of PKI certificates.

Gerald Steere provides some defensive advice:
“It is hard to defend against federation attacks, but if you compare logs from both sides, finding something unusual is a dead give away. Comparing issuance of tokens from the identity provider against logins to your cloud services for example”


Protecting ADFS Servers

This all means that federation servers, including ADFS servers, need to be protected at the same level of Domain Controllers (Tier 0).

Securing ADFS Recommendations:

  • Only Active Directory Admins and ADFS Admins have admin rights to the ADFS system.
  • Reduce local Administrators group membership on all ADFS servers.
  • All cloud admins use Multi-Factor Authentication (MFA).
  • Minimal administration capability via agents.
  • Limit access on-network via host firewall.
  • Ensure ADFS Admins use Admin Workstations to protect their credentials.
  • Place ADFS server computer objects in a top-level OU that doesn’t also host other servers.
  • All GPOs that apply to ADFS servers should only apply to them and not other servers as well. This limits potential privilege escalation through GPO modification.
  • Ensure the installed certificates are protected against theft (don’t store these on a share on the network) and set a calendar reminder to ensure they get renewed before expiring (expired certificate breaks federation auth).
  • Set logging to the highest level and send the ADFS (& security) logs to a SIEM to correlate with AD authentication as well as AzureAD (or similar).
  • Remove unnecessary protocols & Windows features
  • Use a long (>25 characters), complex password for the ADFS service account. A Group-Managed Service Account is ideal since AD will manage the account password automatically.
  • Update to the latest ADFS version for security and logging improvements (as always, test first).

Some useful PowerShell commands for documenting ADFS configuration:

Identify Administrators

# Adapted from
$Members = @()
#Invoke-Command {
$Members += net localgroup administrators | where {$_ -AND $_ -notmatch "command completed successfully"} | select -skip 4
$LocalAdmins = New-Object PSObject -Property @{
 Computername = $env:COMPUTERNAME
 Group = "Administrators"
 Members = $Members

On the ADFS server, there are ADFS PowerShell cmdlets. We can identify what they are by running the following command:

Get-Command -module ADFS

The ones I find most useful are:

  • Get-ADFSCertificate
    • The Get-ADFSCertificate cmdlet retrieves the certificates that the Federation Service uses for token signing, token decrypting and securing service communications. Keep an eye on expiration dates.
  • Get-AdfsAdditionalAuthenticationRule
    • The Get-AdfsAdditionalAuthenticationRule cmdlet retrieves the global rules that govern all applications that trigger additional authentication providers to be invoked. When the claim engine evaluates the additional authentication rules and determines that multiple factor authentication is required, the user is prompted to perform additional authentication. Use this rule only when all your applications are capable of performing web based credential collection through Active Directory Federation Services (AD FS). Applications that use protocols like WS-Trust will fail to obtain a security token if the trigger is true as a result of evaluation of the rules.
  • Get-AdfsAttributeStore
    • The Get-ADFSAttributeStore cmdlet retrieves the attribute stores of the Federation Service. You can use this cmdlet with no parameters to retrieve all the attribute stores of the Federation Service.
  • Get-AdfsAuthenticationProvider
    • The Get-AdfsAuthenticationProvider cmdlet gets a list of all authentication providers currently registered in Active Directory Federation Services (AD FS). The read-only list includes built-in and external authentication providers and associated properties.
  • Get-AdfsClaimDescription
    • The Get-ADFSClaimDescription cmdlet retrieves the claim descriptions that are in the Federation Service. Claim descriptions describe the claims that the Federation Service uses. They also describe how these claims are published in federation metadata. You can use this cmdlet without parameters to get the full list of claim descriptions.
  • Get-AdfsClaimsProviderTrust
    • The Get-ADFSClaimsProviderTrust cmdlet retrieves the claims provider trusts in the Federation Service. You can use this cmdlet with no parameters to get all the claims provider trust objects.
  • Get-AdfsClient
    • The Get-AdfsClient cmdlet retrieves registration information for an OAuth 2.0 client that was previously registered with Active Directory Federation Services (AD FS).
  • Get-AdfsEndpoint
    • The Get-ADFSEndpoint cmdlet retrieves a specified endpoint from the Federation Service. The collection of ADFSEndpoint objects is a list of all the supported endpoints that are on the server. You can use this list to view the configuration of endpoints and enable or disable them. To see the full list of endpoints, use this cmdlet with no parameters.
  • Get-AdfsGlobalAuthenticationPolicy
    • The Get-AdfsGlobalAuthenticationPolicy cmdlet displays the global authentication policy, which includes the providers currently allowed as additional providers in the AdditionalAuthenticationProvider property.
  • Get-AdfsGlobalWebContent
    • The Get-AdfsGlobalWebContent cmdlet gets all global web content objects or the global web content object that corresponds to the locale that you specify. If you do not specify the Locale parameter, the cmdlet gets global web content objects for all locales.
  • Get-AdfsProperties
    • The Get-ADFSProperties cmdlet retrieves the properties of the Federation Service.
  • Get-AdfsRelyingPartyTrust
    • The Get-ADFSRelyingPartyTrust cmdlet retrieves the relying party trusts in the Federation Service. You can use this cmdlet with no parameters to get all relying party trust objects.
  • Get-AdfsSslCertificate
    • The Get-AdfsSslCertificate cmdlet gets the host name, port, and certificate hash for all SSL bindings configured for Active Directory Federation Services (AD FS) and, if enabled, the device registration service.
  • Get-AdfsSyncProperties
    • The Get-ADFSSyncProperties cmdlet retrieves the configuration database synchronization properties of the Federation Service.
  • Get-AdfsWebApplicationProxyRelyingPartyTrust
    • The Get-AdfsWebApplicationProxyRelyingPartyTrust cmdlet gets the Web Application Proxy relying party trust object for the proxy.
      The Web Application Proxy relying party trust is useful to manage global network access from outside the corporate network. By setting authentication and authorization policies, an administrator can restrict access to internal web applications and services that are published through the Web Application Proxy.
  • Get-AdfsWebConfig
    • The Get-AdfsWebConfig cmdlet gets Active Directory Federation Services (AD FS) web customization configuration settings.
  • Get-AdfsWebTheme
    • The Get-AdfsWebTheme cmdlet gets AdfsWebTheme objects. Specify a web theme by name. If you do not specify a name, the cmdlet gets all the AdfsWebTheme objects.

Here are a few ADFS PowerShell commands we use to check for certain configurations:

# Ensure lockout threshold < AD lockout
Get-AdfsProperties | fl ExtranetLockoutEnabled,ExtranetLockoutthreshold,ExtranetObservationWindow

# Set to >1 years
Get-ADFSProperties | Select CertificateDuration

Write-Output "ADFS Server Logging Level:"


ADFS References

(Visited 35,447 times, 3 visits today)


    • Brad on November 28, 2017 at 5:02 pm

    Curious as to why you recommend extending the certificate duration from the default of 1 year all the way to 5 years. I mean, I guess if the token signing certificate is compromise it probably doesn’t make a practical difference if the access is 1 year or 5 years. Realistically it’d be great if relying parties used idp metadata to get the new certificate and rollovers could happen very frequently. Still, 5 years is a long time for any certificate to be valid without a really good reason.

    1. Agreed. 1 year is probably too short. We just use this as a check to see that the certificate will be available for a while. 5 years may be too long, but better than expiring.
      We’ll review this guidance. Thanks!

Comments have been disabled.