Exchange Server Extended Protection

Extended Protection uses service binding and channel binding to help prevent an authentication relay attack. In an authentication relay attack, a client that can perform NTLM authentication (for example, Windows Explorer, Microsoft Outlook, a .NET SqlClient application, etc.), connects to an attacker (for example, a malicious CIFS file server). The attacker uses the client's credentials to masquerade as the client and authenticate to a service (for example, an instance of the Database Engine service).  This is to help protect against Machine In The Middle (MITM) attacks which may also be called Attacker In The Middle Attacks (AITM).

Consider a scenario with three participants: a client, server, and attacker. The server has the URL https://server, whereas the attacker has the URL https://attacker. The attacker tricks the client into accessing the attacker as if it were the server. The attacker then sends a request to the server. If the attacker is trying to access a secure resource, the server replies to the attacker with a WWW-Authenticate header. The attacker does not have the authentication information, so it sends the WWW-Authenticate header on to the client. The client sends the Authorization header to the attacker, and the attacker sends the header on to the server and gets access to the secure resources using the client’s credentials.

Currently, when a client application authenticates itself to the server using Kerberos, Digest, or NTLM using HTTPS, a Transport Level Security (TLS) channel is first established and authentication takes place using this channel. However, there is no binding between the session key generated by Secure Sockets Layer (SSL) and the session key that is generated during authentication. So, in the previous scenario, if the communication takes places over a TLS (such as an HTTPS channel), there are two SSL channels created: one between the client and the attacker, and another between the attacker and the server. The client’s credentials are sent from the client to the server first over the SSL channel between the client and the attacker and then over the channel between the attacker and the server. Once the client’s credentials reach the server, the server verifies the credentials without detecting that the channel over which those credentials were sent originated with the attacker and not the client.

The solution is to use a TLS-secured outer channel and a client-authenticated inner channel, and to pass a Channel Binding Token (CBT) to the server. The CBT is a property of the TLS-secured outer channel, and is used to bind the outer channel to a conversation over the client-authenticated inner channel.

In the previous scenario, the CBT of the client-attacker TLS channel is merged with the authorization information that is sent to the server. A CBT-aware server compares the CBT contained in the client authentication information, which corresponds to the client-attacker channel, to the CBT attached to the attacker-server channel. A CBT is specific to a channel’s destination, so the client-attacker CBT does not match the attacker-server CBT. This lets the server detect the MITM attack and refuse the authentication request.

The client side does not require any configuration setting. Once the client has been updated to pass the CBT to the server, it always does so. If the server has also been updated, it can be configured to use the CBT or ignore it. If it has not been updated, it ignores it.

The server can have the following levels of protection:

• None. No channel binding validation is performed. This is the behavior of all servers that have not been updated.
• Partial. All clients that have been updated must provide channel binding information to the server. Clients that have not been updated do not have to do so. This is an intermediate option that allows for application compatibility.
• Full. All clients must provide channel binding information. The server rejects authentication requests from clients that do not do so.

For Exchange specific articles please see:

Extended Protection enabled in Exchange Server (KB5017260)

Exchange Server Support for Windows Extended Protection

Released: August 2022 Exchange Server Security Updates

Note that there are multiple considerations and caveats that must be considered and reviewed prior to implementing Extended Protection on Exchange.  They will change over time, so please ensure you are reviewing the latest guidance.

Let’s take a look at enabling Extended Protection in an environment.

Lab Starting Environment

We know there is work to do as the wonderful Exchange HealthChecker script has identified that there is an issue.   It has detected that Extended Protection is not enabled properly.

Security Vulnerability: CVE-2022-24516, CVE-2022-21979, CVE-2022-21980, CVE-2022-24477, CVE-2022-30134   Extended Protection isn't configured as expected

It helpfully links to the public GitHub page referenced above.

For more information about Extended Protection and how to configure, please read this article:   https://aka.ms/HC-ExchangeEPDoc

Fixing It Manually

This is probably not the way to do.  The strong recommendation is to use the automated script that was developed specifically for this purpose.  That is covered in detail in the next section.

But it is still worthwhile to look at what is actually being changed.  If we open the IIS Manager and go to a virtual directory, note the options in the right hand pane.

The Advanced Settings can be modified to enable Extended Protection.

We want to automate this change so that it is done consistently across all machines.  As an added bonus, the script provides an easy back out also.

Yet another reason to use it.

Review Blog Posts & Documentation

As noted above, please take the time to understand what this feature does and what it does not do.  You must understand your environment and how it is deployed so you can determine if there are issues.

Install Exchange Updates

Ensure all Exchange servers are current on updates.

Verify TLS Configuration

Ensure that the TLS configuration is perfect in the environment.  Again use the HealthChecker to ensure that *ALL* the registry keys are set as expected.  The script to enable Extended Protection will also run the same checks.  Much better to have this squared away in advance.

In this lab only TLS 1.2 is used.  Other protocols are disabled.  Note that TLS 1.3 is null as that is not supported at this time for Exchange, and especially not on Exchange 2016.

The same precision needs to be applied to the .NET and cipher suite configuration.

Review Know Issues

Please review the latest update to the known issue list

Extended Protection - Microsoft - CSS-Exchange

Review Script Parameters

The various script options can be reviewed and tested in the lab prior to using the script in production.

ExchangeExtendedProtectionManagement - Microsoft - CSS-Exchange

Note that there options which will require a list of Exchange servers.

 

Enabling Extended Protection – Modern Hybrid

If you use Modern Hybrid, the servers that run the agent need to be excluded from Extended Protection at this time.

You can use the SkipExchangeServerNames parameter.  An example is show below.

.\ExchangeExtendedProtectionManagement.ps1 -RestrictType EWSBackend -IPRangeFilePath "IPList.txt" -SkipExchangeServerNames HybridServer1, HybridServer2

List Out Exchange Servers

This will be required to generate a list of Exchange servers that are set to bypass the back end web site restriction.  This is the current workaround for environments that use MRM policies to move items to the archive mailbox.  More on that in the next section.

.\ExchangeExtendedProtectionManagement.ps1 –FindExchangeServerIPAddresses

The IP List file has a simple layout, and can contain either individual IPs or CIDR ranges.

Once you have generated the list it may need to be edited for larger environments to reduce the number of entries.

MRM Move To Archive Consideration

The IP list can be used to allow MRM move to archive tasks on the EWS back end virtual directories.  The -RestrictType switch needs to be specified.

Executing the script this way, configures extended protection on all vDirs like scenario except the Back End/EWS vDir, where it sets the Extended Protection setting to OFF. The Extended Protection setting is required to be turned OFF to ensure automated archiving works without any hinderance.

As turning OFF Extended Protection settings in Backend EWS vDir is not recommended, this script mitigates the risk by limiting the incoming connections to Backend EWS vDir. The script does this by installing an IIS module called IP Address and Domain Restriction and adding allow rules for IP addresses of Exchange Servers. It then adds a deny rule for any incoming connections which is not present in the list.

The file should contain only IP addresses or IP subnets of Exchange servers separated by newline character. For customers who have more than 100 servers, it is recommended to use IP subnets instead of IP addresses, so that the list is short and efficient.

.\ExchangeExtendedProtectionManagement.ps1 -RestrictType EWSBackend -IPRangeFilePath "IPList.txt"

Enabling Extended Protection

Once we have read the documentation, known issues and made sure that the prerequisites are in place we can execute the change.

When the script is executed, it will note that there are certain scenarios that will not function.  This is in addition to the other pre-flight checks that the script makes.

Extended Protection is recommended to be enabled for security reasons. Known Issues: Following scenarios will not work when Extended
Protection is enabled.
- SSL offloading or SSL termination via Layer 7 load balancing.
- Automated Archiving using Archive policy.
- Exchange Hybrid Features if using Modern Hybrid.
- Access to Public folders on Exchange 2013 Servers.
You can find more information on: https://aka.ms/ExchangeEPDoc. Do you want to proceed?

.\ExchangeExtendedProtectionManagement.ps1 -RestrictType EWSBackend -IPRangeFilePath "IPList.txt"

As noted earlier, the script will run and perform a series of pre-flight checks.  Especially around TLS configuration as this is part of how Extended Protection operates.

The prerequsites checks all completed, so now the script enables Extended Protection.

As a text excerpt:

All servers that we are trying to currently configure for Extended Protection have RPC (Default Web Site) set to false for SSLOffloading.
Exch-2016: Backing up applicationHost.config.
EXCH-2016: Successful backup to C:\windows\System32\inetsrv\config\applicationHost.cep.20221208021256.bak
Exch-2016: Successfully updated applicationHost.config.
Exch-2019: Backing up applicationHost.config.
EXCH-2019: Successful backup to C:\windows\System32\inetsrv\config\applicationHost.cep.20221208021231.bak
Exch-2019: Successfully updated applicationHost.config.

Successfully enabled Extended Protection: Exch-2016, Exch-2019
Successfully updated IP filtering allow list for VDir Exchange Back End/EWS on server Exch-2016
Successfully updated IP filtering allow list for VDir Exchange Back End/EWS on server Exch-2019
Do you have feedback regarding the script? Please email ExToolsFeedback@microsoft.com.

 

Verification

Once the script has finished, re-run the healthchecker script and verify all functionality in the enviroment.

 

Backout

If you need to back the change out, the script can roll the changes back.  This is possible since backups of the current configuration are made when the script is executed.

Note that there are a couple of different ways that the backout can be executed.

If you want a full rollback of the Extended Protection and IP Restriction Rules:

.\ExchangeExtendedProtectionManagement.ps1 –RollbackType RestoreIISAppConfig

If you want to roll back only the IP allow and deny rules in the backend EWS vDir

.\ExchangeExtendedProtectionManagement.ps1 -RollbackType RestrictTypeEWSBackend

Cheers,
Rhoderick