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 properly securing relying party trusts on AD FS servers in terms of the signature hash algorithm.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Server Core Windows Server 2016 installations.

Why look at the signature hash algorithm for AD FS Relying Party Trusts

Active Directory Federation Services (AD FS) signs its tokens to relying party trusts, like Azure Active Directory to ensure that they cannot be tampered with.

This signature can be based on SHA1 or SHA256. Azure Active Directory supports tokens signed with an SHA256 algorithm since October 2016, and recommends setting the token-signing algorithm to SHA256 for the highest level of security.

Reasons why

Federation servers require token-signing certificates to prevent attackers from altering or counterfeiting security tokens in an attempt to gain unauthorized access to federated resources.

The private/public key pairing that is used with token-signing certificates is the most important validation mechanism of any federated partnership because these keys verify that a security token was issued by a valid partner federation server and that the token was not modified during transit.

It would be a shame if information could be created that would unlock the information encrypted through a collision attack, but that’s exactly what Google announced on February 2017 for SHA1 certificates after two years of research in collaboration with the CWI Institute in Amsterdam.

This collision attack urges to move from SHA1 to safer alternatives, such as SHA256.

Possible negative impact (What could go wrong?)

If changing the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256 goes wrong, the functionality of the relying party trust becomes unavailable, in other words; access to the application or all applications connected to the platform on the other side of the relying party trust becomes unavailable.

If the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256 change goes wrong for the ‘Microsoft Office 365 Identity Platform’ relying party trust, then access to popular functionality like Exchange Online, SharePoint Online, Teams, PowerBI and Dynamics 365 is lost and needs to be rebuild.

Getting Ready

To change the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256, 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 create and/or change and link Group Policy objects to the Organizational Unit (OU) in which the AD FS servers reside.

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 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.

Important:
It is especially important to communicate to the teams that are responsible for the functionality connected through AD FS, as you must use the same algorithm for the AD FS RPT as the service provider on the other side of the RPT is expecting, SHA-1 or SHA-256, to generate the hash.

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.

How to do it

To get an overview of the AD FS RPTs that do not use SHA256 as the AD FS token-signing hash algorithm, run the following line of Windows PowerShell when logged on with an account that has local administrative privileges on the Primary AD FS server:

Get-AdfsRelyingPartyTrust | select Name,SignatureAlgorithm

This will provide the names of the RPTs and their SignatureAlgorithm properties.

You can change the AD FS token-signing hash algorithm for an AD FS relying party using the following lines of Windows PowerShell when logged on with an account that has local administrative privileges on the Primary AD FS server:

$RPT = 'Microsoft Office 365 Identity Platform'

Set-AdfsRelyingPartyTrust -TargetName $RPT –SignatureAlgorithm `
'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'

Roll-back

To roll back the change, run the following lines of PowerShell when logged on with an account that has local administrative privileges on the Primary AD FS server:

$RPT = 'Microsoft Office 365 Identity Platform'

Set-AdfsRelyingPartyTrust -TargetName $RPT –SignatureAlgorithm `
'http://www.w3.org/2000/09/xmldsig#rsa-sha1'

Concluding

Changing the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256 from SHA1 provides a much smaller risk of collisions and therefore increases information security.

Make sure the service providers offering functionality through AD FS relying party trusts support SHA256 as the token-signing hash algorithm before changing it to avoid (temporary) loss of functionality.

Further reading

Change signature hash algorithm for Office 365 relying party trust
Token-Signing Certificates
Configuring the AD FS Token Signing and -Decrypting Certs for a longer lifetime