Extended Protection for Microsoft Exchange Server (KB5017260)

Microsoft has recently released a security update for Exchange servers that requires the enabling of "Extended Protection" in the IIS virtual directories to mitigate new vulnerabilities such as authentication relay or "man in the middle" attacks. This release has suggested that SSL Offloading the connection before reaching Exchange, such as on a Load Balancer, will no longer work when Extended Protection is enabled. This article will outline the implications of this change in more detail and provide a workaround when using the LoadMaster to load balance Exchange.

Product: Any

Version: Any

Platform: Any

Application: Exchange Server 2013, 2016 & 2019

Enabling Extended Protection on Exchange servers can break connections that are SSL Offloaded but not re-encrypted on the LoadMaster.

The connection flow that breaks is as follows:

Client HTTPS > LoadMaster Virtual Service (SSL Offloaded) > Exchange Server HTTP (unencrypted).

Re-encrypting the traffic between the LoadMaster Virtual Service and Exchange server using HTTPS avoids this incompatibility when Extended Protection is enabled.

Microsoft has released a security update for Exchange server 2013, 2016 & 2019 recommending that Extended Protection is enabled. However, this can cause problems for traffic that is SSL Offloaded on the LoadMaster and not re-encrypted before reaching the Exchange server.

SSL Offloading:

Terminates the connection on a device between the client and the Exchange Server and then uses a non-encrypted connection to connect to the Exchange Server.

Client --[HTTPS]-> [Device (e.g., Load Balancer) terminates the connection] --[HTTP]-> Web Server

SSL Offloading scenarios are not supported:

Extended Protection is not supported in environments that use SSL offloading. 
SSL termination during SSL offloading causes Extended Protection to fail. 
To enable Extended Protection in your Exchange environment, you must not be using SSL offloading with your Load Balancers.

Note: Microsoft will provide additional guidance for this scenario in the near future.

Refer to following link for full details: Extended Protection - Microsoft - CSS-Exchange

If Extended Protection is enabled on Exchange Servers and the traffic is being Offloaded by the LoadMaster then the connection will break as the Exchange server will see the Offloading as a possible "man in the middle" attack.

To get around this issue "Reencrypt" must be enabled under the SSL properties of the Exchange Virtual Service.

Modify (Exchange Virtual Service) --> SSL Acceleration --> Reencrypt.

In order for this to work the Microsoft outlines that the Load balancer performing the reencrypt and the backend Exchange server must share the same SSL Certificate:

SSL Bridging (SSL Reencrypt):

Is a process where a device, usually located at the edge of a network, decrypts SSL traffic, and then re-encrypts it before sending it on to the Web server.

Client --[HTTPS]-> [Device (e.g., Load Balancer) terminates the connection] --[HTTPS]-> Web Server

SSL Bridging (SSL Reencrypt) supported scenarios:

Extended Protection is supported in environments that use SSL Bridging under certain conditions. 
To enable Extended Protection in your Exchange environment using SSL Bridging, you must use the same SSL certificate on Exchange and your Load Balancers. 
If not this will cause Extended Protection to fail.

In addition to sharing a common SSL Certificate the Exchange real servers may have a requirement to run a PowerShell command in order to enable SSL Bridging/reencrypt. The command should look similar to the following:

Set-OutlookAnywhere -Identity '<EXCHANGE_SERVER_NAME>\<VirtualDirectory> (Default Web Site)' -SSLOffloading $false -InternalClientsRequireSsl $true -ExternalClientsRequireSsl $true

where <EXCHAGE_SERVER_NAME> should be replaced with the actual exchange server name and <VirtualDirectory> should be replaced with the virtual directory of the Exchange serve such as ECP, OWA, RPC etc.

IMPORANT NOTE: The executions of PowerShell commands on Exchange Servers is the responsibility of the Server Administrator and should be carried out with care outside production hours where possible in order to avoid impacting production traffic. It is advised that these changes should be performed during a scheduled maintenance window.

Once the exchange servers have had SSL Bridging/Reencrypt enabled Microsoft provides a script that can be run in order to enable extended protection across the exchage service.

The script along with full details and instructions can be found at the below links:

ExchangeExtendedProtectionManagement - Microsoft - CSS-Exchange

IMPORANT NOTE: The executions of PowerShell scripts on Exchange Servers is the responsibility of the Server Administrator and should be carried out with care outside production hours where possible in order to avoid impacting production traffic. It is advised that these changes should be performed during a scheduled maintenance window.

Since documentation is subject to change please refer to Microsoft documentation for up to date information about the implementation and execution of PowerShell commands and PowerShell scripts in respects to Windows Extended Protection.

In the case that there are issues with configuring SSL Reencrypt between the LoadMaster and the Exchange Server there is an alternative work around that will allow the use of Extended Protection where by SSL Acceleration is disabled completely on the LoadMaster.

For this workaround to work it is advised that a new virtual service should be deployed. Once the new service has been configured and tested a change can be made to the Virtual IP between the test virtual service and the production virtual service by going to:

View Modify Service --> Modify --> Change Address

Once this change is implemented the traffic should then route to the newly configured virtual service.

1. First create a new Virtual Service under a new Virtual IP address.

View Modify/Service --> Add New

2. Modify the newly deployed service.

View Modify/Service --> Modify

3. Under the Basic Properties set the "Service Type" to be HTTP - HTTP/2 - HTTPS

Basic Properties --> Service Type --> HTTP - HTTP/2 - HTTPS

4. Add your real server:

Real Server --> Add New --> Enter Exchange Server IP/Port --> Add this new server

5. Configure the real server health check method:

Real Server --> Real Server Check Method --> HTTPS

Refer to the below screenshot.

If you have more than one Exchange Server in the pool then "Persistence" must also be enabled and a "Persistence Timeout" must be configured.

Standard Options --> Persistence Options --> Mode --> Source IP.

and

Standard Options --> Persistence Options --> Timeout--> <Set a preferred timeout in hours/minutes>

Refer to the below screenshot.

Extended Protection enabled in Exchange Server (KB5017260):

https://support.microsoft.com/en-us/topic/extended-protection-enabled-in-exchange-server-kb5017260-edee0d85-f65e-4e19-a52c-e63583ce9727#:~:text=Extended%20Protection%20enhances%20the%20existing%20authentication%20functionality%20in,be%20supported%20on%20servers%20that%20run%20Exchange%20Server

Exchange Server Support for Windows Extended Protection:

https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/

Manuel Enablement of Windows Extended Protection:

Released: August 2022 Exchange Server Security Updates - Microsoft Tech Community

Microsoft PowerShell Script for enabling Windows Extended Protection :

ExchangeExtendedProtectionManagement - Microsoft - CSS-Exchange

SSL Accelerated Service:

https://support.kemptechnologies.com/hc/en-us/articles/5143461977357-SSL-Accelerated-Services