Exchange Server Extended Protection

Exchange 2019 CU14

In Exchange 2019 CU14, Microsoft enabled Extended Protection by default in an attempt to prevent Man-in-the-Middle attacks. When not prepared or configured properly, enabling Extended Protection can have serious consequences. The worst scenario that I have seen recently is that users were no longer able to logon to Exchange 2019 after applying CU14.

Extended Protection is not new. Microsoft introduced the feature in Windows 2008 R2 Internet Information Server (IIS 7.5). Support for Exchange 2019 came with the August 2022 Exchange Server Security Updates. This Security Update was available for Exchange 2019 CU12 and CU13, for Exchange 2016 CU22 and CU23, and Exchange 2013 CU23. However, these updates did not enable extended protection.

In a previous article, I described how Exchange uses SSL Certificates. Here, I dig deeper into TLS and explain what Extended Protection is, how it works in IIS, and how to configure extended protection for Exchange Server.

Web Servers, TLS, and Extended Protection

Using certificates, a connection between a client and a server is encrypted and authenticated. When a client sets up a connection to a server, the following steps occur:

1. The client requests the IP address of the server using DNS and opens a TCP connection on port 443.
2. The client sends a TLS Hello message to the server. This message contains the TLS version it supports, the possible cipher suites for encryption and a random string of bytes called the ‘client random’.
3. The server responds with a Hello message containing the chosen cipher suite, a ‘server random’, and the SSL certificate.
4. The client verifies the SSL certificate. It must contain the URL that the client used to access the server and the client checks if the certificate is not expired or revoked by the the certification authority that issued it. This way the client knows that the server really is who it says it is.
5. The client sends another random string, the ‘premaster secret’. The secret is encrypted using the public key of the SSL certificate and can only be decrypted by this server using the private key of the SSL certificate.
6. The client and the server both generate session keys from the server random, the client random, and the premaster secret.
7. The client sends an encrypted ‘finished message’ to the server and the server also responds with an encrypted ‘finished message’.

This process is called the TLS handshake and when finished, an encrypted connection exists between the client and the server (Figure 1).

Figure 1 shows a simple representation of a client connecting directly to a server. When using a web farm, or when the client is on the Internet and the web server is on an internal network, a reverse proxy is used to publish the web server(s). A load balancer is often used as a reverse proxy to publish a web server to the Internet.

In this scenario, the steps outlined in the previous example are executed, but the server is now the reverse proxy server and not the web server. When complete, the client has a secured connection with the reverse proxy, and the reverse proxy can decide what to do with the information, like forwarding the request to the web server. Or when a load balancer is used, one of the web servers. The reverse proxy server can use an unencrypted connection with the web server, this is called SSL offloading. The reverse proxy server can set up a secured connection with the web server. The same steps are then executed again, but the client is now the reverse proxy server. This is called re-encryption or SSL bridging and is shown in Figure 2.

Now let’s compare this to the OSI model. The TCP connection is in Layer 4 (Transport Layer) which takes care of a reliable network connection. Layer 6 (Presentation Layer) is where TLS is acting, and the web server is in Layer 7 (Application Layer). This is shown below in Figure 3.

TLS authenticates servers against the SSL certificate, and if a server or device can present the correct certificate, all is good and communication takes place, regardless of any man in the middle. This is where Extended Protection begins to play a role.

Extended Protection uses a token generated when a user is authenticated (in the Application Layer on the server) and binds it to the TLS session setup in Layer 6. This is called the ‘channel binding token’. It binds the user’s authentication session to the device’s TLS session, and it is only valid for that session. A Man in the middle attack cannot take over a session and use the token to set up other sessions. This is why it does not work when SSL offloading is used. Taking over a session by a Main in the Middle attack is called a session relay or authentication relay.

Extended Protection in Exchange Server

IIS in Windows Server supports Extended Protection since IIS version 7.5 in Windows Server 2008 R2. Starting with Exchange 2019 CU14 Extended Protection is enabled by default. Be aware, Microsoft introduced Extended Protection in the August 2022 Security Updates, so it is available for Exchange 2016 CU22/CU23 and Exchange 2013 CU23, even if it is not enabled by default.

So, when is special attention needed when installing CU14 and configuring Extended Protection?

• You cannot use SSL offloading with Extended Protection since it cannot use the channel binding token. It is possible to use re-encryption on a load balancer (also known as SSL bridging), but only when the same SSL certificate is used on the load balancer and the Exchange servers.
• When using a load balancer with pre-authentication configured, even with a correct re-encryption configured, it will break and it is not possible to log on to the Exchange servers anymore.
• Make sure that Extended Protection is enabled on all Exchange servers in your organization and that all SSL certificates on the Exchange servers are identical.
• Outlook Anywhere has SSL offloading enabled by default, when installing Exchange 2019 the installer will disable SSL offloading. A better solution is to switch from Outlook Anywhere to MAPI/Http.
• Take care when using Public Folders hosted on an older version of Exchange server when installing Exchange 2019 CU14. Public Folders must be hosted on Exchange 2016 CU23 or Exchange 2019 CU14, or the Public Folder access will break. You can find more information regarding Public Folders and Extended Protection in the Microsoft article Configure Windows Extended Protection in Exchange Server.
• Extended Protection only works with a classic hybrid environment. When using modern hybrid, Extended Protection cannot be used and must be disabled when installing CU14.

Before installing Exchange 2019 CU14, or before enabling Extended Protection on Exchange 2016 or Exchange 2013, it’s important to run the Microsoft Healthchecker.ps1 script, and to check TLS settings on your Exchange servers. Make sure that TLS 1.2 is enabled on all Exchange servers. I recommend only using TLS 1.2 and disabling TLS 1.0 and TLS 1.1 for all Exchange servers.

Using the healthchecker.ps1 script, check the Extended Protection settings on all Exchange servers in your organization. As shown in Figure 4, Extended Protection is not enabled on my Exchange 2019 servers before installing Exchange 2019 CU14.

When installing Exchange 2019 CU14 using the GUI setup application, the setup application automatically enables Extended Protection. It is not possible to avoid this using the GUI. If you need to install Exchange 2019 CU14 without enabling Extended Protection, use the unattended setup with the /DoNotEnableEP_FEEWS switch. Use the following example to install Exchange 2019 CU14 without enabling Extended Protection:

Setup.EXE /Mode:Upgrade /IAcceptExchangeServerLicenseTerms_DiagnosticDataOn /DoNotEnableEP_FEEWS

When you have installed CU14 and need to disable Extended Protection for some reason, use the ExchangeExtendedProtectionManagement.ps1 script provided by Microsoft.

To show the status of Extended Protection, use the following command. This is shown in Figure 5.

.\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

It is possible to use IIS Manager on an Exchange server to change the Extended Protection session, as shown in Figure 6. It is strongly recommended NOT to change these settings this way and should use the Microsoft script instead.

Summary

Extended Protection is a Windows feature that mitigates Man-in-the-Middle attacks. It does this by using a ‘channel binding token’ to bind an authentication session to a TLS session. Starting with the August 2022 Security Update for Exchange server 2013/2016/2019 Extended Protection is supported, but not enabled by default. Exchange 2019 CU14 enables Extended Protection by default.

Before installing Exchange 2019 CU14, make sure you have all the prerequisites in place. If you cannot have this in place, you can install CU14 with the /DoNotEnableEP_FEEWS switch to not automatically enable Extended Protection. When you have the prerequisites in place, you can enable Extended Protection using the Microsoft script. Use the Microsoft script and avoid using Windows IIS Manager. It’s the right way to do things.