Exchange 2019 CU14 is expected to enable Windows Extended Protection in Exchange Server by default. This feature enhances the existing authentication in Windows Server and mitigates authentication relay or man-in-the-middle (MitM) attacks..
Extended Protection requires several very important prerequisites, which the link above describes.
Prerequisites for enabling Extended Protection on Exchange Server:
- SSL offloading must be disabled on all Exchange servers (it's enabled by default).
- Clients should use NTLMv2 instead of NTLMv1, which is the default setting in Windows. I recommend configuring this via Group Policy. If NTLMv1 is used by clients when Extended Protection is enabled, the configuration leads to password prompts on the client side without a way to authenticate successfully against the Exchange server.
- TLS configurations must be consistent across all Exchange servers within the organization. Any variation in TLS version use across servers can cause client connections to fail. I recommend that all Exchange servers be configured to use only TLS 1.2 for client and server operations, as well as .NET.
- Third-Party software running on your Exchange server must be compatible with Extended Protection. Ensure to test all third-party products that are running in your Exchange Server environment to ensure that they work properly when Extended Protection is enabled.
- Extended Protection doesn't work with hybrid servers using a Modern Hybrid configuration.
- Extended Protection can't be enabled on Exchange Server 2013 servers with Public Folders in a coexistence environment.
- Extended Protection can't be enabled on Exchange Server 2016 CU22 or Exchange Server 2019 CU11 or older that hosts a Public Folder hierarchy.
The best course of action is to check and mitigate the Extended Protection prerequisites first. Always read the CU installation notes, especially if you use Windows Update to deploy this security update.
Please reach out to EXPTA Consulting if you would like assistance.