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 look at the extended protection for authentication feature with AD FS.
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 look at Extended Protection for Authentication
To help secure your Hybrid Identity deployments, you can set and use the extended protection for authentication feature with AD FS. This setting specifies the level of extended protection for authentication supported by the AD FS servers in the farm.
Extended protection for authentication helps protect against Man-in-the-Middle (MitM) attacks. In this type of attack, a malicious person intercepts client credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed, or not required by the server when it establishes communications with clients.
Extended Protection for Authentication aims to prevent this type of credential relay. It does this by implementing a protocol based on RFC5056 “On the Use of Channel Bindings to Secure Channels”.
Possible negative impact (What could go wrong?)
When the client doesn’t support the Channel Binding Token (CBT), the authentication will fail. As Windows Authentication is the first negotiated authentication methods for the intranet, clients will use this authentication method by default. When this type of authentication fails, the client may resort to other authentication methods, like Forms authentication, Certificate authentication, Device authentication or Microsoft Passport authentication, if enabled.
By default, Forms authentication, Windows Authentication and Microsoft Passport authentication are enabled as authentication methods for the intranet on Windows Server 2016-based AD FS farms.
Windows 7 and up, and Windows Server 2008 R2 and up support the feature and have the feature enabled, by default. However, older Windows clients, that have not received KB968389, do not support the feature.
Chrome browser versions below version 51 .0.2784 (released on January 24th, 2017) and Firefox don’t support the Extended Protection for Authentication feature.
To enable the Extended Protection for Authentication feature, make sure to meet the following requirements:
If you expect clients to fail integrated Windows authentication when you enable the Extended Protection for Authentication feature, it is wise to assess the impact clearly. You can do so with a test Windows Server that runs Internet Information Services (IIS) version 7.5 or up, and configure it with Extended Protection for Authentication using the steps described here.
The information gathered this way clearly defines the scope and impact. Then, an informed choice can be made to enable and it, or not.
Make sure the AD FS servers are installed with the latest cumulative Windows Updates.
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.
As the Extended Protection for Authentication feature is an AD FS feature that mainly impacts client systems, go and have a chat with the people responsible for managing workstations in the organization. Do they see the same things in terms of scope and impact?
Enabling Extended Protection for Authentication
When all stakeholders are informed and the organization is in agreement that the Extended Protection for Authentication feature adds value, perform these steps:
Check the Extended Protection feature
Check the Extended Protection for Authentication feature status by running the following line of Windows PowerShell:
Get-ADFSProperties | Select ExtendedProtectionTokenCheck
On an AD FS farm running Windows Server 2016 and/or Windows Server 2019 AD FS servers with default settings, the above line of Windows PowerShell would return Allow.
This means the AD FS server in the farm are partially hardened, because the Extended Protection for Authentication is enforced only when clients have been patched to support it.
Configure Extended Protection for Authentication to Require
To fully harden the AD FS Farm, set the Extended Protection for Authentication feature to Require, use the following line of PowerShell on an elevated Windows PowerShell prompt:
Set-ADFSProperties –ExtendedProtectionTokenCheck Require
Testing Extended Protection for Authentication
After enabling the Extended Protection for Authentication feature, it’s time to test. Everyone involved 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? Is the user experience on down-level clients and non-Microsoft browsers still adequate?
Rolling back Extended Protection to default settings
In the case of the Extended Protection for Authentication feature, this security feature can stand in the way of user satisfaction. If so, you might need to roll it back.
To roll-back the AD FS Farm in terms of the Extended Protection for Authentication feature, use the following line of PowerShell on an elevated Windows PowerShell prompt:
Set-ADFSProperties –ExtendedProtectionTokenCheck Allow
Windows Server 2016, by default, comes with the Extended Protection for Authentication feature enabled, but not fully hardened. Configure Extended Protection for Authentication to Require to get the most out of it.
MSRC – Extended Protection for Authentication
Windows Extended Protection <extendedProtection>
Is disabling the ADFS ExtendedProtectionTokenCheck setting required for allowing Firefox and Chrome users to authenticate?