- Pulseway 9.2: Remote monitoring with workflow automation - Thu, May 18 2023
- ENow Active Directory Monitoring & Reporting - Tue, May 16 2023
- Auditing and restricting NTLM authentication using Group Policy - Thu, May 11 2023
Windows Extended Protection uses channel binding and service binding to provide additional validation that a logon session is intended for a specific resource.
- Channel binding uses a channel binding token (CBT), such as is used with SSL connections.
- Service binding uses a service principle name (SPN) primarily in cases where connections are made through a proxy server or load balancer or connections that do not use SSL.
Recently, in response to zero-day attacks targeting Exchange Server, Microsoft has implemented Windows Extended Protection as an additional means to increase security as part of its recommended guidance with Exchange Server security updates.
How does Windows Extended Protection (WEP) work?
Attackers often use social engineering, "man in the middle" attacks, or credential relaying to coerce unsuspecting end users into connecting to a malicious server and exposing their credentials. Consider the example of an attack scenario in which integrated Windows authentication (IWA) is deployed in the environment.
Without Extended Protection, an attacker could get a client to connect to their server, which is impersonating a legitimate server (webmail.mycompany.com), and authenticate using their valid credentials. The attacker could then replay the credentials on another legitimate server in the environment (fileserver.mycompany.com) and authenticate using the stolen credentials.
However, with Extended Protection, if an attacker tries to replay the credentials, the server will validate whether the authentication request was originally intended for itself or another resource. Also, if a TLS channel is established, Windows Extended Protection will validate whether the TLS session is the same as the original session. The server would then validate that the authentication request was not intended for the same resource and would fail the authentication attempt.
Enabling Windows Extended Protection
First, you must have Windows Authentication installed and enabled in IIS. The actual Windows Extended Protection setting is located under the Advanced Settings of Windows Authentication. Possible settings include:
- Off
- Accept
- Required
Enabling Windows Extended Protection in IIS
Exchange Server Windows Extended Protection
Microsoft has introduced support for Windows Extended Protection in Exchange Server 2013, 2016, and 2019, starting with the August 2022 Exchange Server Security Update releases in response to critical vulnerabilities. In addition, Microsoft has provided additional resources by providing sanctioned scripts to help enable the feature on each virtual directory contained on an Exchange Server installation.
The scripts helps to automate the process, as Exchange Server has a multitude of directories that can leverage the extra security provided by Windows Extended Protection. Additionally, due to the number of changes needed, Microsoft recommends using the script instead of manually introducing the changes. You can read the full documentation and download the latest version here.
Downsides to using WEP on Exchange
As with most other security protections and mitigations, it brings its own set of challenges and issues. Several scenarios are not supported when enabling Windows Extended Protection. Note the following and the workarounds proposed by Microsoft:
- SSL offloading or SSL termination via Layer 7 load balancing—Causes Extended Protection to fail.
- Automated archiving using Archive Policy—If you are using automated archiving, you will need to run the ExchangeExtendedProtectionManagement.ps1 script with Extended Protection off on the backend EWS directory. However, it adds an IPRangeFilePath parameter to add a filter of IPs allowed to the backend EWS directory to mitigate the risk.
- Exchange Hybrid features—There is a workaround if you are using the hybrid configuration. You can skip Exchange Servers that are published using the Hybrid Agent.
- Access to public folders on Exchange 2013 servers—If you are running Exchange Server 2013, you must ensure you do not have any public folders. If you are in a coexistence configuration with Exchange 2013 and Exchange 2016 or 2019, public folders need to be migrated to 2016 or 2019 before Extended Protection is enabled. Any public folders on Exchange 2013 after Windows Extended Protection is enabled will no longer be visible to end users.
Read further details on configuring Extended Protection in the above scenarios here.
Wrapping up
With the August 2022 Exchange Server security updates, Extended Protection is introduced to help mitigate authentication attacks and bolster the verification of authentication against virtual directories in Exchange Server.
However, customers must pay attention to the scenarios and configurations that may have issues, such as Exchange Server 2013 public folders.
Subscribe to 4sysops newsletter!
You can read more about the August 2022 Exchange Server security guidance here.
