In Part 1 the basic configuration of Sophos XG in connection with Exchange 2016 has already been carried out, but some configuration work is still missing so that Outlook Anywhere, MAPIoverHTTP and the REST Api also work. As already in part 1 As mentioned above, the Sophos templates for business applications are somewhat outdated, so they need to be corrected manually. It is somewhat irritating that there are three templates for Exchange. The "Exchange General" template deals with the classic web services such as OWA, EWS and ActiveSync, but also contains completely outdated paths for OMA (Outlook Mobile Access), which has not been used for a long time.
If the three standard templates are used, it is necessary to separate the Exchange web services (OWA, EWS, ActiveSync, etc), Autodiscover and Outlook Anywhere (RPC, MAPI) from each other. However, this also means that a SAN certificate with three names (Subject Alternate Names) must be used.
It can also be a little nicer, at least for the current protocols.
Redirection from "/" to "/owa"
With the standard rules, only a 404 error page is displayed when the root folder is called up:
Normally, the Exchange server performs the redirect to /owa here. To achieve this, the "Exchange 2016 Webservices" rule can be adjusted:
A new path can now be added in the "Protected servers" section:
A slash "/" is entered here as the path and the Exchange Server is selected as the web server. Authentication remains empty:
A new exception is then created in the "Exceptions" section:
A slash "/" is again entered as the path and "Static URL hardening" is excluded as a check:
The firewall rule can now be saved and the redirection to /owa will work again.
MAPIoverHTTP (/mapi)
MAPIorHTTP can also be activated quite easily. The "Exchange Webservices" rule is edited again:
This time, two new paths are created in the "Protected server" area:
The paths "/mapi" and "/MAPI" are now created here. The web server is again the Exchange server, authentication remains empty:
After the two paths have been created, the overview looks as follows:
Finally, the existing option must be edited:
The two paths "/mapi/*" and "/MAPI/*" are now added to the list of paths for the exception:
The list of exceptions is now as follows:
Note: When I created this screenshot, I noticed that I forgot to delete the exceptions for "/oma/*" and "/OMA/*" (blue box). These two paths can be deleted without replacement. Outlook Mobile Access (OMA) has not been used for a long time and is no longer available on an Exchange 2016 server.
After the firewall rule has been saved, MAPIoverHTTP (the new Outlook Anywhere) works.
REST API (/api)
Although the REST API has not yet been officially released with the CU4 version for Exchange 2016, it is already available for testing. The standard rules do not take the new API into account either, so it must be released in the same way as MAPIoverHTTP.
Here again, as with MAPIoverHTTP, the Exchange Web Services Firewall rule is adapted and two new paths are added. This time "/api" and /"API":
The paths "/api/*" and "/API/*" are then entered in the existing exception list:
The exception list should now look like this:
The firewall rule can now be saved and the REST API works.
RPCoverHTTP (/rpc)
The classic Outlook Anywhere (RPCoverHTTP) is a little trickier. Here it is advisable to consider beforehand whether this Protocol still requiredbecause all Outlook versions supported by Exchange 2016 also speak MAPIoverHTTP.
I would do without RPCoverHTTP at this point, at least if only two hostnames are available, as in my case. The background to this is that most of the web server protection mechanisms for Outlook Anywhere have to be switched off. This then also applies to the other web services such as OWA and EWS. If Outlook Anywhere, i.e. the classic RPCoverHTTP, is still required, I recommend adding a third host name to the certificate (e.g. rpc.frankysweb.de) and adapting the Exchange configuration to this host name (as also provided by Sophos). In this way, a new business application rule from the template can be used to deactivate only the necessary protection mechanisms for Outlook Anywhere (RPCoverHTTP) and not for all other services.
I tried it anyway to see if it is possible to get by with two hostnames and two firewall rules: Yes, it is possible, but it sucks, because in my opinion it effectively disables web server protection. Almost all features have to be deactivated. Since I think this configuration is so unclean, I don't want to publish it. If you insist, you can write me an e-mail and I'll send you a little HowTo.