Why Exchange SE CU1 is breaking my legacy integrations

Hi Hardeman Saul

As far as I know, this behavior occurs because the CU1 update automatically hardens the authentication methods of the IIS virtual directories to "Negotiate:Kerberos" to enhance security and phase out NTLM.

So, we can say that there are no hidden registry keys or system configurations available to enable an automatic NTLM grace period, which means legacy devices incapable of processing Kerberos tickets are immediately denied access at the server level.

In order to resolve this permanently and maintain future stability, you must manually configure Service Principal Names (SPNs) for all load-balancer aliases to satisfy the Kerberos authentication requirements.

Additionally, for immediate emergency service restoration, you can temporarily use PowerShell to inject NTLM back into the IISAuthenticationMethods parameter for specific endpoints (such as using the Set-WebServicesVirtualDirectory cmdlet).

Run the following commands to force the system to accept NTLM alongside Negotiate (Kerberos) for EWS and Autodiscover—the two endpoints most commonly used by legacy devices and internal apps.

For EWS:

Set-WebServicesVirtualDirectory -Identity "YOUR_SERVER_NAME\EWS (Default Web Site)" -IISAuthenticationMethods Ntlm, Negotiate

For Autodiscover:

Set-AutodiscoverVirtualDirectory -Identity "YOUR_SERVER_NAME\Autodiscover 

Hope this helps

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Exchange Server SE CU1 moving to stronger Kerberos defaults aligns with the broader Kerberos hardening changes described for Windows domain controllers. These changes remove a lot of the “it just works” fallback behavior that previously masked misconfigurations or legacy-only (NTLM/RC4) dependencies.

From the available information, there is no documented “NTLM grace period” or registry flag that reverts the security posture back to pre‑hardening behavior. The guidance is explicitly to avoid workarounds that keep non‑compliant devices and protocols alive, because they reintroduce the vulnerabilities these updates are designed to close.

Key points from the Kerberos hardening behavior that affect environments like this:

1. Common encryption type is now mandatory
   After the November 8, 2022 updates on domain controllers, all devices must share at least one common Kerberos encryption type. Environments that previously worked because DCs silently added RC4 or AES no longer get that automatic help. Behavior now strictly follows:
   • msds-SupportedEncryptionTypes on the account, or
   • DefaultDomainSupportedEncTypes on the DC if the account’s value is empty or 0.
2. Non‑Windows and legacy devices must be updated or replaced
   For non‑Windows devices (such as older scanners or appliances) that cannot support AES ticket signing or a compatible Kerberos encryption type, the official guidance is:
   • Update to the latest firmware/software and ensure a common encryption type with the DCs.
   • If that is not possible, contact the OEM or replace the devices.
   • Workarounds to allow non‑compliant devices to authenticate are explicitly not recommended because they make the environment vulnerable.
3. Unsupported Windows versions and legacy protocols
   Devices on unsupported Windows versions (XP, Server 2003, 2008 SP2, 2008 R2 SP1) cannot be accessed by updated Windows devices unless covered by ESU and fully patched. If updates are not available, the only supported paths are upgrading or moving workloads to compliant systems.
4. Registry behavior for encryption types
   Domain controllers use DefaultDomainSupportedEncTypes (under HKLM\System\CurrentControlSet\services\KDC) when msds-SupportedEncryptionTypes is not set on an account. The default value 0x27 (DES, RC4, AES session keys) was chosen as the minimum change for the security update. Recommended values are:
   • 0x3C for stronger security (AES tickets and AES session keys), or
   • 0x38 for AES‑only environments where RC4 is not used.
   This key can be manually added/changed to adjust which Kerberos encryption types are allowed, but it does not provide an NTLM rollback switch; it only controls Kerberos encryption types.
5. Detection and preparation steps
   To prepare and troubleshoot:
   • Verify that all devices (including Exchange, load balancers, and legacy apps that can use Kerberos) share at least one common Kerberos encryption type.
   • On DCs with the post‑November 8, 2022 updates, look for Microsoft-Windows-Kerberos-Key-Distribution-Center Event 27 to identify devices with disjoint encryption types.
   • Adjust msds-SupportedEncryptionTypes on affected accounts or DefaultDomainSupportedEncTypes on DCs as needed, within the supported and recommended values.
6. No supported “turn it back to NTLM” switch
   The documentation around these Kerberos changes is clear that Microsoft does not recommend workarounds to keep non‑compliant devices authenticating. There is no supported registry flag described that would re‑enable legacy NTLM behavior as a temporary grace mode once the hardening is in place. The supported options are:
   • Bring devices and applications into compliance (Kerberos with supported encryption types, ideally AES), or
   • Replace or relocate workloads that cannot be made compliant.

In practice, this means the environment is effectively in a “fix it or it stays broken” posture from a supportability and security standpoint. Any attempt to re‑enable broad NTLM fallback or weaken Kerberos beyond the documented knobs (like DefaultDomainSupportedEncTypes) would fall outside the recommended and supported configuration and re‑open the vulnerabilities these updates address.

References:

• KB5021131: How to manage the Kerberos protocol changes related to CVE-2022-37966