Configuration Challenges with Office Web Applications, SSL Offloading and Default Zone URL’s

Configuring Office Web Applications in a development or test environment is a pretty straightforward process: install the server bits, run a bit of PowerShell to create a WAC farm, set your WOPI bindings in SharePoint, and you’re done. But doing so in a full production environment, with high availability, SSL offloading, split DNS, HTTPS redirection, fully-qualified AAM’s and multiple web application zones? That’s an entirely different ball game.

Consider the following real-world scenario. The SharePoint farm, which has been built following high-availability guidelines for redundancy, has both internal web servers for employees and external web servers for customers. The customer servers are in a DMZ behind a dedicated load balancer, with their own Virtual IP’s, but they still have to be reached by internal employees and connect to the rest of the SharePoint farm, so they use a split-DNS scheme to provide name resolution internally and externally. The web applications were created on HTTP, with the appropriate alternate access mappings, as the SSL certificates reside on the load balancer, where any incoming requests from the outside network get automatically redirected to HTTPS but are passed to the servers as standard HTTP.

Office Web Apps Farm in DMZ with SharePoint 2013/2016

In this configuration, internal employees can browse to http://extranet.contoso.com without the need to manage certificates on the servers themselves and without ever transiting the corporate firewall. External users who forget to type "https" before hitting the extranet site get conveniently redirected to a secure connection on a load-balanced IP address and the web server traffic is isolated from the rest of the farm. So far, so good. But what about giving customers and partners the same online document viewing/editing experience as internal users? Wouldn’t it be great if they could also take advantage of the Office Web Applications functionality in SharePoint? Yes, it would – but getting it to work properly is going to take a bit more planning than usual.

The first challenge is determining where the WAC servers should reside. For security and traffic isolation purposes it is best to co-locate the WAC farm with the SharePoint servers in the DMZ. Placing them on the internal network will result in direct client connections to internal resources when users open documents in Word/Excel/PowerPoint online; a situation which should be avoided and which would likely fail a security audit. It’s one thing for web servers to communicate to the back end via their own connections but quite another when external users are hitting URLs from an outside network that should otherwise be off-limits.

There are, however, some significant ramifications to what is otherwise a clear choice. Since there is a one-to-many relationship between WAC farms and SharePoint farms, it means that the WAC farm must either be located entirely in the external zone or have at least two servers in the internal zone and two in the external zone (for minimal redundancy). Spanning the zones requires virtual IP’s on both the internal and external load balancers along with corresponding DNS entries in both zones. Configuring the WAC farm will also require some creative DNS configuration and port rules, as the servers have to be aware of each other and be able to communicate on port 809 (if you are using the standard configuration of HTTP on 809 and HTTPS on 810). Alternatively, the entire WAC farm can reside externally and internal users would simply get flipped over to HTTPS when they try to open documents in the browser.

Configuration user connectivity to the WAC servers is actually quite simple; however, getting the WAC servers to talk to SharePoint is not quite so easy. When WAC receives a client request for a document, it attempts to load the document from the SharePoint site the user was browsing when they made the initial request. If the user is external, that means the request will go from https://extranet.contoso.com to https://wac.contoso.com with the load balancer handling the SSL portion of the communication and passing it to WAC as a standard HTTP request. This means the WAC farm must have been created using the "SSLOffloaded" switch, the WOPI zone set to "External-HTTPS" (so it creates both internal and external bindings), and the WOPI binding configured with the "AllowHTTP" options. WAC then has all the proper settings to make the request to SharePoint for the desired document.

Or does it?

This is where things start to get very interesting. The way WAC functions, it will only make a request to SharePoint on the URL for the web application’s default zone. With SSL offloaded at the load balancer, this is usually an HTTP endpoint – in this case, http://extranet.contoso.com. But when the WAC servers in the external zone try to reach this URL, they will receive an IP resolution from the external DNS server that points to the external VIP on the load balancer which, when it receives such a request, automatically flips the "http" to "https". Since WAC doesn’t know what to make of a redirect happening in the middle of an attempt to retrieve a SharePoint document the request will fail and the user will receive the dreaded "Sorry, there was a problem and we can’t open this document" error. Adam Rhinesmith, who is a support escalation engineer on the Microsoft Office Web Client and Services team, pointed this out on a blog post back from 2014 but the ramifications of what he was saying aren’t immediately apparent until you come across this general scenario.

So how can we allow both internal and external users to load documents in WAC and still maintain some level of traffic isolation? One option is to by pass the load balancers by pointing the WAC servers to internal SharePoint servers which will respond to the HTTP request using host entries on each WAC machine. Similarly, another web server could be added to the farm in the DMZ but not to the load balancer virtual IP configuration, which would make it reachable only by the WAC servers over HTTP (again, using host entries). But managing host entries, especially in the case of Host Named Site Collections, on each WAC server can be tedious and prone to error. Another option is to point the WAC severs to the internal DNS or have a separate DNS server in the DMZ with internal entries, so that the WAC requests are never routed to the external servers at all. Since WAC only needs to talk to SharePoint and the other WAC servers this is a approach that scales much easier in the context of Host Named Site Collections. In my opinion, the preferred approach is a combination of these two options, with a dedicated SharePoint web server in the DMZ that does not participate in the load balancing pool (the only function of which is to serve WAC requests) and a separate DNS server for name resolution of the WAC farm servers and HNSC hosts. In this configuration, the only WAC-related traffic that crosses from the external to the internal zone is WAC farm communication over port 809 which is, IMHO, an acceptable compromise. One final option, if you have the hardware to support it, is to create a rule on the load balancer not to translate HTTP traffic to HTTPS if it originates from the WAC servers.

NOTE: It is worth pointing out – in fact, SHOULD be pointed out – that if the entire farm were configured for HTTPS as it should be then this situation wouldn’t arise at all, along with saving many other headaches and making the overall farm more secure. Bear that in mind before trying to avoid HTTPS due to minimal cost increases or supposed ease of configuration.

So the moral of this story is to carefully consider the configuration of your WAC farm when setting up SharePoint servers in a DMZ where SSL traffic is terminated at a load balancer. If external users cannot open documents in WAC but internal users can then you are very likely running up against the default URL zone HTTP/HTTPS issue. There may be other creative ways to overcome this limitation besides those I’ve covered above but however you do there needs to be a way for the WAC servers to communicate with the SharePoint servers using the URL and protocol associated with the web application default zone. Otherwise, external users will be forced to use desktop clients to open documents. Surely with all the goodness in Office Web Applications nobody wants that, do they?

​​