Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.
In this part of the series, we’ll harden the AD FS Server installations, by disabling unnecessary endpoints they offer.
Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Windows Server 2016 Server Core installations. The same information applies to AD FS Servers running Windows Server 2016 with Desktop Experience (Full).
Why harden AD FS Servers
Hardening provides additional layers to defense in depth approaches. It changes the default behavior of products and services to make them more resilient to unauthorized changes and compromise.
Reasons why
Active Directory Federation Services (AD FS) servers are typically placed on the internal network, close to Active Directory Domain Controllers. In a typical Hybrid Identity Implementation, the AD FS Servers is published using Web Application Proxies.
It is imperative that endpoints that are offered by AD FS Servers do not allow for nefarious possibilities. This is why Microsoft has started to disable several endpoints by default on Windows Server 2016-based AD FS Servers, like the IdP-initiated Sign-on page.
Possible negative impact (What could go wrong?)
When endpoints on AD FS servers are disabled, while they are needed, certain functionality may be lost, until the endpoint is enabled again.
The Windows Transport endpoints mentioned in this blogpost are needed for several purposes, including Hybrid Azure AD Join, in the internal network. However, it is a recommended practice to remove these endpoints for the extranet (The Internet in AD FS terms). If the endpoints are completely disabled, the internal functionality may be lost (until the endpoint is enabled again).
Getting ready
To disable unnecessary endpoints on AD FS servers, make sure to meet the following requirements:
System requirements
Make sure the AD FS servers are installed with the latest cumulative Windows Updates.
Privilege requirements
Make sure to sign in with an account that has privileges to manage the AD FS Farm. In case of Windows Internal Database (WID) as the storage method for the AD FS Configuration database, sign in with an account that has local administrator privilege on the primary AD FS Server.
Who to communicate to
As the AD FS servers operate as part of a chain, notify all stakeholders in the chain. This means sending a heads-up to the load balancer guys and gals, the networking guys and gals, the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It’s also a good idea to talk to the people responsible for backups, restores and disaster recovery.
One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.
Unnecessary AD FS Endpoints
IdP-Initiated Sign-On endpoint
In Windows Server 2016-based AD FS Farms, the IdP-initiated Sign-on page is disabled, by default. However, since many admin tricks rely on this page, this endpoint is often temporarily enabled to allow for:
- Testing the correct functionality of AD FS Servers.
- Testing branding of the sign-in pages for situations where Single Sign-On is not available.
For the first purpose, use the /adfs/probe endpoint over HTTP to see if an AD FS Server is actually responding and runs the AD FS service. Use the /adfs/trust/mex endpoint over HTTPS to test issues with the TLS certificate. There is no need to abuse the /adfs/ls/idpinitiatedsignon.aspx endpoint for that…
For the second purpose, I’d like to remind you that in many environment nothing is as permanent as temporary solutions. Once the IdP-initiated Sign-on page is enabled, it’s hard to keep in mind to disable it again, when done.
Windows Transport Endpoint
In Windows Server 2016-based AD FS Farms, the windows transport endpoints are enabled, by default. It is recommended that the endpoint be disabled from the extranet due to a known security vulnerability; these endpoints allow NTLM logins to be processed from the extranet. As a result, it will bypass AD FS lockout protections and allow brute force password attacks or account lockouts on the user account.
Note:
Azure AD Connect Health for AD FS prompts for security warnings about WS-Trust endpoints since the last week of July 2019.
The Windows Transport endpoints need to be immediately disabled from being exposed to the extranet.
How to disable unnecessary AD FS endpoints
Please run the following lines of Windows PowerShell to configure the AD FS Farm:
Set-AdfsProperties –EnableIdpInitiatedSignonPage $False
Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/2005/windowstransport -Proxy $false
Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/13/windowstransport -Proxy $false
Testing proper hardening
After hardening it’s time to test the hardening. Everyone should sign off (not literally, unless that’s procedure) on the correct working of the AD FS servers. Does authentication to cloud applications still work? Does rolling over the certificate still work? Does monitoring still work? Can we still make back-ups? Can we still restore the backups we make?
As endpoints apply to all AD FS servers in the farm, there is no need to isolate an AD FS server in the load-balancer; the above lines of PowerShell apply to all AD FS Servers within a timeframe of about 5 minutes.
Rolling back hardening
To roll back hardening of the endpoints to Windows Server 2016’s default state, run the following lines of Windows PowerShell:
Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/2005/windowstransport -Proxy $true
Set-AdfsEndpoint -TargetAddressPath `
/adfs/services/trust/13/windowstransport -Proxy $true
Concluding
Disable the IdP-initiated Sign-on page and Windows Transport endpoints on the AD FS farm to harden AD FS Servers.
Good article but is there a way to identify if these endpoints are in use through some windows events
Hi Farooque,
They shouldn't be in use.
If they are in use, than it's an unsafe configuration and the practice should stop.
That not what he asked. Unsafe doesnt mean not functioning. We like to keep things operating safe or not so we can remain employed. He wants to know how do we tell if everything will stop functioning if we disable either of these transports?
To see the URLs that are accessed on the AD FS infrasrtructure, perform these steps:
Get-WinEvent -FilterHashtable @{LogName="Security";ID=403} |
%{ $_.Properties.Value -join " " }
This provides a list of the actual HTTP GET requests and the URLs accessed on the AD FS server.
If you see the endpoints in this list, then they are used. Note, however, that we disable some endpoints for external use only, so filter out the internal IP addresses for these endpoints.