0

Updated Guidance On Exchange Server Extended Protection

Extended Protection (EP) was added to Windows back in 2009 as a new security feature. This feature enhances the protection and handling of credentials when authenticating network connections using Integrated Windows Authentication (IWA).

The update itself does not directly provide protection against specific attacks such as credential forwarding, but allows applications to opt-in to Extended Protection for Authentication.  Please also review KB5021989: Extended Protection for Authentication. This security update modifies the Security Support Provider Interface (SSPI) to enhance the way Windows authentication works so that credentials are not easily forwarded when IWA is enabled.

When EPA is enabled, authentication requests are bound to both the Service Principal Names (SPN) of the server the client tries to connect to and to the outer Transport Layer Security (TLS) channel over which the IWA authentication occurs.

The update adds a new registry entry to manage Extended Protection:

  • Set the registry SuppressExtendedProtection

This value is located under:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA

SuppressExtendedProtection

Type: REG_DWORD

0 Enables protection technology.
1 Extended Protection is disabled.
3 Extended Protection is disabled and channel bindings sent by Kerberos are also disabled, even if the application supplies them.

Default value: 0x0

Note: A problem that occurs when EPA is enabled by default is described in the Authentication failure from non-Windows NTLM or Kerberos servers topic on the Microsoft website.

Extended Protection & Exchange Server

Update: 28-8-2023 Coming Soon: Enabling Extended Protection on Exchange Server by Default

Extended Protection enhances the existing authentication functionality in Microsoft Exchange Server to help mitigate authentication relay or Attacker In The Middle (AITM) attacks. To safeguard servers against authentication relay attacks, the Extended Protection feature of Windows authentication can be enabled on supported versions of Exchange Server.

Support for Extended Protection in Exchange server was first added with the August 2022 security update (SU).

There was an update in September 2022 for Extended Proection on Exchange Server.  This update was to provide a workaround for Message Record Management (MRM) activities.

There was a subsequent update in the October 2022 Security Update as Outlook connectivity and Compliance Managed Availability probes were failing after Extended Protection was enabled.

Customers using a Retention Policy containing Retention Tags which perform Move to Archive actions should not configure Extended Protection, as enabling Extended Protection will cause automated archiving to stop working.

 

 

The Exchange Healthcheck Script provides a quick link to the documentation at https://aka.ms/ExchangeEPDoc.  There is a note documenting a change for Extended Protection:

After initial release, we have updated Default Website/OAB to be Accept/Allow instead of Required. This is because of Outlook for Mac clients not being able to download the OAB any longer with the Required setting.

Below is an example of lab server that was set up with the initial relase Extended Protection script.  The updated Healthcheck script correctly detects that Extended Protection is set to Required on the OAB vDIR.

Extended Protection is set to Required on the OAB vDIR

For the search engines:

Default Web Site/OAB - Current Value: 'Require'   Expected Value: 'Allow'

The current Extended Protection settings may cause issues with some clients types on this protocol.
It is recommended to set the EP setting to the recommended value if you are having issues with that protocol.
More Information: https://aka.ms/ExchangeEPDoc

Once all issues are remediated, it would expected that the Exchange Health Check script would look like the example below.

Note that there are zero security issues that are called out.

Exchange HealthCheck Script - Issues Remediated

 

Cheers,
Rhoderick

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *