AD FS – Troubleshooting TLS version errors when configuring WAP trust with AD FS

Hi all. Today I will share with you some steps to help you troubleshoot TLS version mismatch that break the trust between Web Application Proxy and AD FS servers.

Note: In this demonstration, I will use AD FS version 2019. It’s possible to have a different event ID if you are running another AD FS version. In case of doubt, use this link to match the correct event ID to your AD FS version: https://adfshelp.microsoft.com/AdfsEventViewer/GetAdfsEventList

If your WAP and AD FS servers cannot establish a TLS communication properly, the trust will break and you might start having problems to authenticate users from the internet. Some errors you might face when trying to reestablish the trust are mentioned below:

Error: The federation server proxy configuration could not be updated with the latest configuration on the federation service.
Event Logs:
AD FS/Admin
Log Name: AD FS/Admin
Source: AD FS
Event ID: 1130
Task Category: None
Level: Error
Keywords: AD FS
Description: There was an error establishing or renewing the proxy trust. Ensure the STS and proxy servers have the same TLS version enabled.

Log Name: AD FS/Admin
Source: AD FS
Event ID: 224
Task Category: None
Level: Error
Keywords: AD FS
Description:
The federation server proxy configuration could not be updated with the latest configuration on the federation service.
Additional Data
Error: Retrieval of proxy configuration data from the Federation Server using trust certificate with thumbprint ‘THUMBPRINT’ failed with status code ‘InternalServerError’.

AD FS Tracing/Debug
Log Name: AD FS Tracing/Debug
Source: AD FS Tracing
Event ID: 996
Task Category: None
Level: Error
Keywords: ADFSDiagnostics
Description:
Data in the original trace event ‘STSErrorTraceEvent’ is logged individually in this event to prevent potential loss of data.
Original Event : STSErrorTraceEvent
Mode details: Data Error: Exception: An error occurred when attempting to establish a trust relationship with the federation service. Error: The underlying connection was closed: An unexpected error occurred on a send. StackTrace: at Microsoft.IdentityServer.Management.Proxy.Providers.ProxyTrustProvider.EstablishTrustWithSts(ICredentials credentials, String thumbprint) at Microsoft.IdentityServer.Deployment.Core.Tasks.ConfigurationTaskBase.Execute(IDeploymentContext context, IProgressReporter progressReporter) Exception: The underlying connection was closed: An unexpected error occurred on a send. StackTrace: at System.Net.HttpWebRequest.GetResponse() at Microsoft.IdentityServer.Management.Proxy.Providers.ProxyTrustProvider.EstablishTrustWithSts(ICredentials credentials, String thumbprint) Exception: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

Why TLS handshake?

The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish or resume secure sessions and is used by the Web Application Proxy service to establish secure communication to the federation server before establishing the trust. More information about the TLS handshake, please check this link: https://docs.microsoft.com/en-us/windows/win32/secauthn/tls-handshake-protocol

Investigating TLS version

In order to investigate if the communication between WAP and AD FS servers over TLS is working correctly, follow steps below:

Step 1

• Install network monitor in the WAP server to collect a network trace while configuring the trust.
• Use filter TLS to see the TLS handshake between client (WAP) and server (AD FS).
• Expand TLS parameter and check which TLS version is used by the WAP server to communicate with AD FS server.

Step 2

Run the commands below on AD FS servers to see if the respective TLS version above is enabled.

Example: As TLS 1.0 is used by WAP server in this demonstration, run commands below to check if TLS 1.0 is Enabled in the AD FS server.

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client' | Select Enabled,DisabledByDefault

Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server' | Select Enabled,DisabledByDefault

Expected Output:

Cause:
Many customers are considering the option to disable TLS 1.0 and RC4 protocol on AD FS, and replace it with TLS 1.1 or a later version.
You might have more information about this in this document: https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/disable-and-replace-tls-1dot0#summary

Fix:
If TLS 1.0 is disabled in AD FS, guarantee that all WAP and AD FS servers use the latest TLS version following steps below:

Step 1:
Enable TLS 1.2 on WAP servers running commands below:

New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null
New-Item 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'Enabled' -value '1' -PropertyType 'DWord' -Force | Out-Null
New-ItemProperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client' -name 'DisabledByDefault' -value 0 -PropertyType 'DWord' -Force | Out-Null

Enabling Strong Authentication for .NET applications

The .NET Framework 3.5/4.0/4.5.x applications can switch the default protocol to TLS 1.2 by enabling the SchUseStrongCrypto registry key. This registry key will force .NET applications to use TLS 1.2.

Starting with AD FS on Windows Server versions 2012 R2 and 2016, you need to use the .NET Framework 4.0/4.5.x key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319

For the .NET Framework 4.0/4.5.x use the following command:

New-ItemProperty -path 'HKLM:\SOFTWARE\Microsoft\.NetFramework\v4.0.30319' -name 'SchUseStrongCrypto' -value '1' -PropertyType 'DWord' -Force | Out-Null

Restart all servers that had the TLS registry keys updated to take effect.

Run command Install-WebApplicationProxy again to re-establish the trust between WAP and AD FS:

Check event 245 on AD FS Admin logs on WAP server:

Log Name: AD FS/Admin
Source: AD FS
Event ID: 245
Task Category: None
Level: Information
Keywords: AD FS
Description:
The federation server proxy successfully retrieved and updated its configuration from the Federation Service ‘sts.contoso.com’.

Confirming client TLS version with network trace

With TLS 1.2 configured as the preferred method on WAP servers, we see TLS handshake completed successfully and confirm that WAP is now using TLS 1.2 on Network trace.

Summary

In this article, we covered some steps to troubleshoot errors related to TLS version mismatch when establishing trust between WAP and AD FS.

I hope you have enjoyed reading this article and it helps you when administering your AD FS environment.

Enjoyed the article? Like and share. 🙂

In case you have any suggestion or feedback, please leave a comment.

[ ]’s

Ulysses Neves