I feel we are at a crossroads. Five years ago, I made the case for token-signing and token-decrypting certificates in Active Directory Federation Services (AD FS) with a validity of 5-year. Today, I’m making the case for 30-day Token-signing and Token-decrypting certificates, based on my understanding of the UNC2452 attack campaign (also known as ‘SolariGate’).

About the token-signing and token-decrypting certificates

Active Directory Federation Services (ADFS) creates and manages the two certificates used for the tokens issued:

• The token-signing certificate
  The private key of this certificate is used to sign tokens that are issued by the AD FS servers in the AD FS farm. The public key for this certificate is published in the Federation Metadata, so relying party trusts (RPTs) can check the validity and integrity of the issued token. 
• The Token-decrypting certificate
  The private key of this certificate is used to decrypt tokens that have been encrypted by relying party trusts (RPTs) and claims provider trusts (CPTs) with the public key of the certificate. The public key for this certificate is also published in the Federation Metadata.

By default, these certificates are valid for one year from their creation and automatically renew. The renewal process starts 15 days prior to the end of validity. At this moment, a new certificate is created, published and used. Any RPT or CPT that is unaware of the change, breaks. I believe this was the number one headache for AD FS admins in the past couple of years.

What changed?

In the past five years, a lot has changed. Our collective understanding of AD FS and claims-based authentication has grown, our processes to maintain AD FS have matured and attacks have gotten more sophisticated.

The biggest change we made was to allow relying party trusts (RPTs) and claims provider trusts (CPTs) to be configured based on federation metadata.

My previous advice to extend the validity period of the AD FS token-signing and token-decrypting certificates was formed in the days that RPTs and CPTs were created manually, most of the time.

UNC2452 as it relates to Active Directory Federation Services: Golden SAML attacks

The intrusion campaign that focused on compromising SolarWinds as a supplier to many of the biggest names in the industry is known as ‘SolariGate’ and tracked as UNC2452.

The attack chain has many steps. In their Remediation and Hardening Strategies for Microsoft 365 to Defend Against UNC2452 threat research, FireEye concludes that the attackers stole the Active Directory Federation Services (AD FS) token-signing certificate and used it to forge tokens for arbitrary users (known as Golden SAML attacks). This would have allowed the attacker to authenticate into a federated resource provider (such as Microsoft 365) as any user, without the need for that user’s password or their corresponding multi-factor authentication (MFA) mechanism.

I believe the Golden SAML attack can be made less efficient, when we apply the same steps as we do to make Kerberos Golden Ticket attacks less efficient: Limit the time the golden ticket is valid.

By limiting the validity period of token-signing and token-decrypting certificates in AD FS to 30 days, Golden SAML attacks would only work for 15 days.

When attackers need to gain access to the private key every 15 days instead of every 350 days, we might be able to detect them when they access the certificate store in Active Directory, the AD FS configuration database or the certificate store of the AD FS service account.

Requirements

If you want to go the route of 30-day token-signing and token-decrypting certificates, there are three requirements that you should meet:

• Automatic certificate rollover should be enabled.
• All relying party trusts (RPTs) should have been configured based on federation metadata. The Monitor relying party option should be enabled. The Automatically update relying party option should be enabled.
• Any claims provider trust (CPT) should have been configured based on federation metadata. The Monitor claims provider option should be enabled. The Automatically update claims provider option should be enabled.

Checking automatic certificate rollover

To check if automatic certificate rollover is enabled in AD FS, use the following line of Windows PowerShell on the primary AD FS server in the AD FS farm:

(Get-ADFSProperties).AutoCertificateRollOver

Checking Relying Party Trusts

To check all the relying party trusts, use the following lines of Windows PowerShell on the primary AD FS server in the AD FS farm:

$RPTs = Get-ADFSRelyingPartyTrust

Foreach ($RPT in $RPTs) {

Write-Host $RPT.Name -ForeGroundColor Yellow

(Get-ADFSRelyingPartyTrust -Name $RPT.Name).AutoUpdateEnabled

(Get-ADFSRelyingPartyTrust -Name $RPT.Name).MonitoringEnabled

Write-Host

}

For all relying party trusts (RPTs), both properties should return TRUE.

If a relying party trust doesn’t have the Monitor relying party option and/or the Automatically update relying party option enabled, you can enable these options on the Properties screen for the relying party trust. This only works when the relying party trust is configured with a Federation Metadata file that it can monitor and the app automatically updates the file on its end.

Checking claims provider Trusts

To check all the claims provider trusts, use the following lines of Windows PowerShell on the primary AD FS server in the AD FS farm:

$CPTs = Get-ADFSClaimsProviderTrust

Foreach ($CPT in $CPTs) {

Write-Host $CPT.Name -ForeGroundColor Yellow

(Get-ADFSSClaimsProviderTrust -Name $CPT.Name).AutoUpdateEnabled

(Get-ADFSSClaimsProviderTrust -Name $CPT.Name).MonitoringEnabled

Write-Host

}

For all claims provider trusts (CPTs), both properties should return TRUE.

If a claims provider trust doesn’t have the Monitor relying party option and/or the Automatically update relying party option enabled, you can enable these options on the Properties screen for the claims provider trust. This only works when the claims provider trust is configured with a Federation Metadata file that it can monitor and the downstream identity provider automatically updates the file on its end.

Configure 30-day token-signing and token-decrypting certificates

To get the current validity period (in days), use the following line of Windows PowerShell on the primary AD FS server in the AD FS farm:

(Get-ADFSProperties).CertificateDuration

To configure 30-day token-signing and token-decrypting certificates, use the following line of Windows PowerShell on the primary AD FS server in the AD FS farm:

Set-AdfsProperties -Certificateduration 30

Now, nothing happens to the token-signing and token-decrypting certificates after you issue that last one-liner, since both certificates have no issues in their current state. Eventually, near the end of their lifetime, they would automatically roll-over, but we want it to happen now.

We have to tell the certificates to roll over to their new settings. The following two PowerShell one-liners can be used to this purpose:

Update-AdfsCertificate -CertificateType Token-Signing –Urgent

Update-AdfsCertificate -CertificateType Token-Decrypting –Urgent

Concluding

Defending against sophisticated attacks, requires effort from admins. AD FS admins, especially, should make a new trade-off between certificates that have a long validity period and certificates that allow for more (automatic) flexibility.

Limiting the validity period of token-signing and token-decrypting certificates in AD FS to 30 days helps to invalidate Golden SAML attacks and detect attackers. However, it can only be achieved when all relying party trusts and claims provider trusts are configured with monitoring and automatic updating.

This defense method is increasingly effective when combined with an AD FS service account based on a group Managed Service Account (gMSA)

Further reading

Configuring the AD FS Token Signing and -Decrypting Certs for a longer lifetime 
From the field: The Case of the Unstable AD FS Farm 
The WID Service consumes 100% CPU after transitioning AD FS Servers 
A Real-world tested Approach for Transitioning AD FS Servers 
The use of Distributed Key Manager (DKM) in Active Directory Federation Services  
Obtain and Configure TS and TD Certificates for AD FS