Exchange 2013: Sophos UTM 9.2 WAF as reverse proxy for Outlook Anywhere, OWA, ActiveSync and Autodiscover

Foreword

Some time ago, I had already tested some alternatives to Forefront TMG. I had already tested an older version of Sophos UTM. However, version 9.2 is now available, in which the web application firewall (WAF) has been significantly improved, according to Sophos. I therefore took a closer look at Sophos UTM. However, anyone planning to use it in conjunction with Exchange 2013 should read the whole article first, as not everything works as expected. So here are my experiences in my test environment:

This is my standard test environment, 2 Exchange 2013 (CAS + MBX) servers, 1 domain controller, 1 Kemp Loadmaster VLM-2000 and the Sophos UTM 9.2.

Exchange and Domain Controller are installed on Server 2012 R2. All systems are installed as VMs. The Sophos UTM serves as the standard gateway for the VMs and is a member of the Active Directory. For this test, there is also a Windows 8.1 client with Outlook 2013, which is not a member of the Active Directory and wants to use Outlook Anywhere.

I want to use the DNS name "outlook.frankysweb.de" as the access point for Outlook Anywhere, so this name is configured as the internal and external host name:

The selection of the authentication method is also important here, I did not get "Negotiate" or "NTLM" to work with Sophos UTM 9.2 (9.203-3). "Simple" should therefore be selected here. But more on this in a moment.

Note: I have decided to use only 2 hostnames. Autodiscover.frankysweb.de for Autodiscover and outlook.frankysweb.de for Outlook Anywhere, OWA and ActiveSync. There are a few HowTo's that separate all services using their own hostnames and corresponding rules. However, if purchased certificates are used, many hostnames can quickly become expensive.

With Exchange 2013, it is best practice to use the same host name for internal and external access points. With Exchange 2010, the recommendation was still to separate this. I therefore use the DNS name "outlook.frankysweb.de" both internally and externally. Internally, the DNS name "outlook.frankysweb.de" is resolved to the IP of the load balancer. If the clients are on the Internet, the DNS name is resolved to the external IP address of the UTM.

This is where the client is located externally (in my test environment, 192.168.10.0 is the Internet)

and this is where the client is located internally (192.168.200.20 is the IP of the load balancer's virtual service)

Internal clients therefore connect to the load balancer, which then forwards the connection to one of the CAS servers

For the sake of completeness, here is a screenshot of the UTM interfaces (so that there is no confusion between internal and external)

In my test environment, 192.168.100.0/24 is the Internet and 192.168.200.0/24 is the internal network. My Windows 8 test client on the Internet is able to resolve the following DNS names (both to the external IP of the UTM):

• outlook.frankysweb.de
• autodiscover.frankysweb.de

My external computer should now be able to use OWA and Outlook Anywhere, so far the UTM is not configured (no port forward, no WAF), so of course calling the URL https://outlook.frankysweb.de does not work either:

Since I want to use the WAF to publish OWA and Outlook Anywhere on the Internet, an SSL certificate is required, I use my internal CA. For purchased certificates, Autodiscover and Outlook Anywhere DNS Name must be on the certificate as Subject Alternate Name:

I find it easiest to create the certificate on a Windows computer and use the wizard. The certificate then only needs to be exported as a PFX file with a private key and imported again on the UTM:

Next, the Real Webservers are created

The settings are made for both Exchange servers, then it looks like this:

The virtual web server can now be created, the settings are as follows:

After saving, it will look like this:

I have not yet activated the WAF, as I am still creating the exceptions first:

In the request filtering, I then specify all Exchange IIS directories in the common spellings:

/owa/*
/OWA/*
/Autodiscover/*
/Autodiscover/*
/ecp/*
/ECP/*
/ews/*
/EWS/*
/rpc/*
/RPC/*
/oab/*
/OAB/*
/Microsoft-Server-ActiveSync/*
/microsoft-server-activesync/*

The exceptions can then also be switched on directly:

Note: If you want to use the automatic redirection to OWA, you have to enter the root here (redirect from https.//outlook.frankysweb.de to https://outlook.frankysweb.de/owa), then it looks like this:

The WAF can now also be switched on:

As mentioned above, I have not been able to get NTLM or "negotiation" to work as an authentication method. The WAF live log permanently showed HTTP 401 errors. For Outlook Anywhere the authentication can be set via ECP, for Autodiscover it has to be done via shell:

Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WindowsAuthentication $false
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod BASIC -ExternalClientAuthenticationMethod BASIC -IISAuthenticationMethods BASIC
Get-OabVirtualDirectory | Set-OabVirtualDirectory -WindowsAuthentication $false -BasicAuthentication $true
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WindowsAuthentication $false -BasicAuthentication $true

It can take up to 15 minutes for the settings to be transferred to the Autodiscover configuration. So be patient.

Disadvantages:

Checking whether the Exchange server is actually accessible takes too long for my taste. I can easily restart an Exchange server without the UTM recognizing that the server is offline. I have also not found a way to adjust the interval. Here is a screenshot, the UTM thinks the server FWEX1 is still accessible, but the server had been down for 3 minutes at that time.

Unfortunately, the health check files cannot be used either, it seems to only check whether "something" is responding on port 443. HealthCheck would of course be better:

Perhaps this will be improved in the next versions. I could not get NTLM to work. Either Autodiscover did not work, or other features such as OAB Download etc. did not work. I couldn't find any errors with standard authentication, but it only worked reliably when I switched to standard authentication internally and externally. Standard authentication also means that Outlook asks for user and password on startup, which I don't like for internal clients. Actually, "negotiation" should work, if NTLM does not work, then standard. Unfortunately, the fallback from NTLM to standard in conjunction with the WAF does not seem to work either.

Update 1: In the meantime, version 9.204-19 has been released. I can't find any reference to NTLM in the change log, but at least the time-out for the real servers can now be set.

Update 2: Unfortunately, ECP does not work when URL hardening is switched on; as soon as users click on "Options", an error message is displayed:

I have only been able to solve this by switching off URL hardening:

I'm starting to wonder why I don't just create a DNAT entry! With regard to Exchange 2013, this seems to be only partially correct:

http://www.sophos.com/de-de/products/unified/utm/tmg-replacement.aspx

But I'm happy to be proven wrong, so if anyone is interested in getting this topic up and running, please let me know...

Update 3: Thanks to Ulrich's advice, ECP now also works. To do this, the "Never change HTML during URL Hardening or Form Hardening" checkbox must be set in the exceptions:

But now I still have the problem with NTLM.

Sophos also states here that NTLM is currently not working:

http://www.sophos.com/en-us/medialibrary/PDFs/other/tmg-administrators-guide-to-sophos-utm.pdf?la=en (page 37)

Does anyone else have a tip on how it is at least possible to use Basic Authentication externally only? As described above, it only works for me if I switch to Basic Auth. internally and externally. Which just occurred to me... let's test... wait a minute

Update 4: A friend kindly put me in touch with Sophos, which gave me the opportunity to clarify a few open questions and get a sneak preview of the upcoming versions. Sophos also provided me with an advance version of a guide for UTM 9.2 and Exchange, so that this is referenced in the email. Sophos has also given me permission to publish the email here. I really have to praise Sophos (and of course the people involved), because I have rarely experienced such a quick response, including detailed information. Many thanks at this point. Here is the email (without names...)

Hello Frank,

My colleague asked me to look into your feedback. Unfortunately German is not my native language, so please forgive me for answering in English (and any misinterpretation of your email on my part).

With that said, I've taken the liberty of citing your email and answering in-line below:

Here I have the first problem in my test environment:

 

Prerequisites

Now, with that said, make sure your Exchange has been configured to allow Basic authentication on the relevant services (OWA, ECP, OAB, Outlook Anywhere, EWS and Autodiscover).

 

Although I can tell Exchange to please provide NTLM or Negotiate for the authentication of internal clients and Basic for external clients, the detection of whether a client is internal or external no longer seems to work with the WAF switched on. From Exchange's point of view, it looks to me as if the client is internal. Exchange therefore offers NTLM. Which is apparently not possible with the WAF.

I therefore had to switch the internal and external authentication options to BASIC, but this has the effect that Outlook asks for the user name and password when establishing a connection and during setup and no longer passes on the login information. This is not so nice if users have to change their password frequently. It should also be known that Baisc is the less secure authentication method.

It is indeed true that it's beneficial for your internal Exchange clients to use Integrated Windows Authentication (IWA) which negotiates between using either Kerberos or NTLM. This is not disputed for any of these services in our guide (which is a work-in-progress by the way, so please consider the version you received a preview), we only kindly request you to enable Basic Authentication as an additional means of authentication for these services (with the exception of OWA and ECP which will indeed need to be switched from Forms authentication to HTTP 401 authentication).

This setup then allows your internal client to remain using Kerberos or NTLM with the Exchange, whereas external client can use basic authentication if the UTM is configured to preform Reverse Authentication for the Exchange server.

And yes, we are quite aware that Basic Authentication is a rather insecure means of authenticating if not combined with some sort of encryptions such as SSL, which is why we are stressing the use of HTTPS in both external communication (with the clients) and internally (between UTM and Exchange).
The reason we chose to go for Basic Authentication as our default delegation method is that this is compatible with every known backend in both the Windows and Linux based webservers.

What do I enter here if I have an AD forest with several domains? This configuration is not exactly unusual. :

 

In the next screen, select "Basic Authentication" and click "edit" in the left-hand bar.

Enter the default domain (either by NetBIOS name or FQDN) in the default domain name field on the popup.

 

And I don't think this is a viable option either:

 

Alternative UPN domain name

The following is only necessary if the internal domain does not match the email domain AND the customer

wishes to use the users' email addresses instead of their internal UPN. In this example, the internal domain is

example.local and the external domainname is example.com.

 

You can't just change the UPN, which is also used in existing AD structures for various other things. The fact that the internal AD domain name does not match the e-mail domain is probably the case for many companies. Common practice is and was to name the Active Directory "company.local", for example, while the mail domain is "company.com". Larger companies often separate this out further: europe.company.local, asia.company.local etc. It is therefore not possible to configure a uniform UPN here. The next point is that adding a suffix does not automatically result in a valid e-mail address. Many companies use personnel numbers or similar as user names. The normal user name would therefore be something like P12345@europa.firma.local, but the e-mail address is usually vorname.nachnahme@firma.de. Adding a suffix is therefore useless here.

While you are correct that AD domain management can be complex, there is no requirement to use Alternative UPNs for authentication. The reason the guide mentions this is that, for small environments (where the internal domain is firma.local and the external is firma.de) it could be beneficial to add an alternative UPN as it looks a lot neater.

Should you however wish to authenticate using just username and password or UPN and password you are more than welcome to. The UTM will not reject p12345@europa.firma.local as a valid username as long as it is set to perform LDAP authentication based on UPN (such as described in the guide)

Can you explain to me why site-path routing is still used later?

Yes I can, we configure site-path routing because we want to enable different authentication profiles for different paths. This allows one to use UTM based HTTP 401 based authentication for services such as EWS, Autodiscover and Outlook Anywhere, while enabling the use of our UTM forms authentication for functionalities such as OWA and ECP.

It would also be nice if in future versions you could perhaps create a way to configure when a server is considered offline. The background in relation to Exchange is the healthcheck.htm which is generated for each web service and therefore the status of the services and not just the IIS can be checked. Would be a nice feature. Perhaps a small configurable load balancing function could also be added directly in order to supply more powerful servers with more users than weaker ones.

This is indeed a legitimate issue and we are looking into using more accurate healthchecks.

Unequal load sharing however is a whole different concern, as this would require a rather extensive knowledge of the protocol and the metrics involved in either the administrator (who will have to know the approximate number of sessions a server can handle) or the UTM (who would need to estimate the amount of sessions per server based on either a template or some severely complicated calculation based on response times or something).

Long story short: We assume both backend to have roughly equal performance for the sake of keeping it simple.

I have the following comments on the TMG Administrators Guide: The TMG implementations that I have managed all had only one purpose: to publish Exchange and SharePoint on the Internet. I have only very rarely seen all the other functions in use. The usual design was rather: front firewall -> DMZ -> Forefront TMG -> firewall/or internal network. In most cases (as far as I can tell), TMG often only acted as a proxy to publish the services on the Internet. And here we have a few points that many people find annoying:

 

NTLM and Kerberos delegation

Sophos UTM does not support NTLM or Kerberos Constrained Delegation modes of authentication.

 

That's a shame because NTLM is the default authentication for Exchange 2013, and Kerberos would of course be a bonus.

We are indeed quite aware that a lot of TMGs have been deployed in the fashion you've described, which is why our main focus of development in regards to TMG replacement has been in our WAF. This has led to the significant improvements already seen in our 9.2 and it will translate into more TMG-like features being added in future releases.

With that said, we currently do not support NTLM and Kerberos constrained delegation for backend authentication, as our primary focus has been on compatibility with multiple different backends, which precludes the use of NTLM (which is a proprietary Microsoft protocol). With that said, expect Kerberos Constrained Delegation to be added in an upcoming release.

And unfortunately, this was the only way to prevent a user from synchronizing his dozens of private devices with the company mailbox via Outlook Anywhere. You don't want to lose data sovereignty. So I don't want all company emails to be stored on a private, unencrypted laptop:

 

Microsoft UTM has the ability to add X.509 client certificate checks to any Web Listener, allowing only those users that have a valid certificate to access the resource or post their authentication details to TMG.

Sophos UTM does not currently have this functionality.

We have started development on X509 client certificates as additional authentication scheme (similar to our OTP functionality) for the next major UTM release. This is a very crucial feature for us as many governments require some sort of certificate based authentication in order for UTM to be a viable option, so expect to see it in our product soon.

Of course, it would also be nice to keep the number of names on the certificate as low as possible. Wildcard certificates are very expensive and have the major disadvantage that all devices/services etc. have to be equipped with a new certificate in the event of a compromise. In your new howto at least only 3 names are used, but many certificate providers offer cheap certificates with 2 names (mostly autodiscover.domain.tld and whatever.domain.tld) at quite reasonable prices.

The guide configures outlook anywhere on an alternative hostname as we've had some reports of false positives (traffic dropped for looking illegitimate even though it isn't) when combining ECP and Outlook Anywhere in the same firewall profile. While we have yet to consistently reproduce these effects in our testing, we've decided to recommend using different profiles until we're sure these issue do not occur when combining said features.

What is not quite clear to me personally, because I don't know how the WAF works, are the exceptions. First switch it on and then switch it off again by exception? Can't I switch it off straight away?

This is due to the way our WebAdmin configuration works. The firewall profile URL hardening assumes that we know all the exact paths and documents that can potentially exist in the backend server. This is of course impossible in an Exchange environment (due to the type of URLs and HTTP messages being used) so we need to create some exceptions to allow the UTM to filter based on a path (for example we want to block "/" but allow "/owa") but disable blocking the URLs below these virtual directories needed to make Exchange works.

While I understand that this can be a bit cumbersome, we think it is better than the alternative (allowing everything below a certain virtual directory by default). We are a talking about a security product, after all.

I am also missing the following feature, which was easy to implement with TMG: In the Active Directory there were 3 groups (Allow_ActiveSync, Allow_OutlookAnywhere and Allow_OWA) to better control access. User groups get access to OWA, but not to Outlook Anywhere etc. And if Outlook Anywhere is allowed, then only with the appropriate client certificate on the company notebook.

The first part of your configuration is quite simple to mimic using a UTM, simply make sure that the reverse authentication profiles being used for the specific services do not contain the groups you wish to disallow access to a specific resource (for example, only add "Allow_OWA" to the reverse authentication profile for the "/owa/" site path rule).

The certificate authentication however, as mentioned before, will be added soon.

I hope this has helped shed some light on the guide, our product and why we chose to do things in a specific way.

Please feel free to publish this response on your blog and reach out to us with any future questions.

With this information and perhaps a mail or two, a good solution is sure to emerge. Updates can be found here.