Exchange server with 'Windows Extended Protection' behind WAF

We are going to test this the coming week. I will report back, then.

Do a Google on site:community.sophos.com/utm-firewall OWA Autodiscover Outlook Anywhere waf and you'll get many tips.  Einige auf Deutsch.

Cheers - Bob

We activated the Extended Protection yesterday on all Exchange servers and since then, Outlook Anywhere stopped working.

Everything from inside the company works fine, also Smartphones are able to sync mails but Outlook from external connections is not working. So we are doing a rollback.

For a short test we disabled the Webserver Protection and did a 80 and 443 NAT to the Exchange Server and it worked. After enabling the Webserver Protection it Outlook Anywhere stopped working again.

At the Exchange Server Eventlog we see:

An account failed to log on.

Subject:
Security ID: NULL SID
Account Name: -
Account Domain: -
Logon ID: 0x0

Logon Type: 3

Account For Which Logon Failed:
Security ID: NULL SID
Account Name: name.name@company.de (edited)
Account Domain:

Failure Information:
Failure Reason: An Error occured during Logon.
Status: 0xC000035B
Sub Status: 0x0

Process Information:
Caller Process ID: 0x0
Caller Process Name: -

Network Information:
Workstation Name: edited
Source Network Address: edited
Source Port: 34080

Detailed Authentication Information:
Logon Process:
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only): -
Key Length: 0

So we disabled the Extended Protection and everything works through the Webserver Protection again.

Is anyone able to use the Extended Protection together with Exchange Webserver Protection through UTM?

I just got the following feedback from MS:

based on my understanding, the Sophos UTM Webserver Protection intercepts the HTTPS connection (https://assets.sophos.com/X24WTUEQ/at/mb4stbjq36pjm77vn8kvn64z/sophos-utm-web-server-protection-ds.pdf) and so, is considered as a Man-in-the-Middle (MitM) and this is a scenario that Windows Extended Protection actively tries to prevent. Therefore, you see the credential prompts as the server doesn't accept the connection.

If the UTM uses SSL Bridging (Client --HTTPS-- UTM --HTTPS-- Exchange), it's required to use the same certificate on the device between the client and the server (in your case, the UTM). If you perform SSL Offloading (Client --HTTPS-- UTM --HTTP-- Exchange) this isn't supported and will not work together with Extended Protection turned on as we need the certificate for the Channel Binding Token (CBT).

For more information see: https://aka.ms/ExchangeEPDoc

That means the automated LetsEncrypt (on tool at the UTM and one at the EX Server) is dead?!

Same Problem here(UTM). After Update Exchange and enabling EP anything works fine except Outlook from external connections. We disable the extended Protection and open  a ticket to solve the Problem. Seems like the XG works.

As stated in my post below: There is nothing a ticket could solve, because one of the features of EP is eleminating any man-in-the-middle attacks. That means you have to use the exact same certificate at the Exchange and the UTM Webserver Filter. No more Lets Encrypt... We have to buy certs again, that last some years.

Do you request the LE certificate on both the UTM and Exchange seperately or why is it not the exact same certificate?

Yes of course, there is no way (that I know) to export/import the LE-Cert at the UTM or Exchange and import it on the other device automatically / without manual interaction all 2-3 months.

The certificate can be imported from the UTM via a PowerShell script on the Exchange server. That is what we do. Here's a guide (in German):

www.frankysweb.de/.../