Dear LukasSMSFT
NicolasAdams meant not the script to enable Extended Protection, but the one which enables NTLM credentials Relay Protections. Do you have any information on that script as well?
But, now to my real question:
We're hosting an exchange server behind a Microsoft WAP/ADFS Farm. Extended Protection can't be enabled, because in the constellation with WAP/ADFS proper pass-through authentication does not work. A case with Microsoft has been opened (Webmail/OWA does not work, and netiher do Outlook-Clients outside the corporate network).
So, sadly, no extended protection for us.
But reading the internet, there are people saying that completely disabling NTLM on the Exchange-Server should do the trick. That could be accomplished by
- 1st enabling Hybrid Modern Auth (we have that already)
- 2nd implementing a AuthenticationPolicy which blocks legacy auth from mail clients to exchange server (including kerberos!) according to this MS Learn Article: https://learn.microsoft.com/en-us/exchange/hybrid-deployment/block-legacy-auth-2019-hybrid#migration-endpoints-in-microsoft-365
- 3rd disabling NTLMv2 on the exchange server completely according to whatever article you find in the internet (no MS-only resource found, but quite a few article like https://tkolber.medium.com/https-medium-com-tkolber-configure-kerberos-authentication-with-exchange-2019-72293aa234c or https://aventistech.com/kb/enable-kerberos-authentication-in-exchange/ or https://community.spiceworks.com/topic/2337217-exchange-2019-to-be-rid-of-ntlm-i-need-kerberos-configured
Can you give me an answer, if this procedure would indeed work for mitigating the CVE?
We can not yet migrate to EXO because of whatever reasons, but i think we can do in about 6 to 12 months, but i don't want to set up a new load balancer and neither do i want to tell our users that they can now only check mails inside the corporate network.
Thanks for your time, and kind regards,
Dö