Introducing

Auditing access to resources
Windows Server 2016 introduces a new capability that gives IT administrators better audit access to
published resources. Web Application Proxy now adds to every request an X-Forwarded-For (XFF)
header to verify whether the header already exists. If so, Web Application Proxy concatenates the
client IP to this header.
Note XFF is a nonstandard HTTP header that became the de facto standard. It is used extensively
by proxy servers to identify the IP of an originated request. For more information about this, read
the RFC at http://tools.ietf.org/html/rfc7239.
Another important aspect of Web Application Proxy auditing capabilities are the events that are
logged in the Event Viewer. In this release, the Event Viewer includes many more events, such as
analytics and debug logs. You will review some examples of these events in the section "Web
Application Proxy troubleshooting" later in this chapter.
Taking application proxies to the modern IT world
A few years ago, our team had a big dilemma. We had two products in the market: Forefront Threat
Management Gateway and Forefront Unified Access Gateway. Both of these products had been
around for many years and had been deployed by tens of thousands of customers. Both of them
had evolved since they were first introduced during the 1990s.
However, both products had similar issues: They were very complex products that were difficult to
deploy, troubleshoot, and maintain. This was partly because over the years they accumulated many
capabilities that became irrelevant. At the same time, they lacked or had limited support for
modern technologies such as federation and OAuth2. On top of it all, they were expensive products
that had their own licenses.
It was a tough decision, but we decided to start from a blank page, to examine all the functionality
of reverse proxy, to pick and choose only the technologies that matter today, and to implement
them by using a fresh code base built on the most modern standards. A big part of this decision
was that we wanted to embed the reverse proxy into Windows Server. We wanted to make it just
like any other role service available to install from Server Manager. For us, this meant adhering to
the strictest standards regarding code and management. Microsoft customers expect that all
Windows Server role services are managed the same way, including in Windows PowerShell, the
administrator UI, the remote administrator UI, performance counters, the System Center Operations
Manager pack, event logs, and so on.
This is how Web Application Proxy was born in Windows Server 2012 R2. We made no compromise
on code security, management, and standardization. And, we were happy that customers got it.
Companies were able to deploy and integrate Web Application Proxy into their infrastructure very
easily.
The downside of this approach is that we were not able to include all of the functionality we wanted
to have—functionality that would make it possible for all customers to move from Threat
Management Gateway and Unified Access Gateway to the new solution. However, now that we
have built a solid foundation, it is easier to add more functionality to make Web Application Proxy
the obvious choice to publish on-premises resources such as Microsoft SharePoint, Lync, and
Exchange to remote users. This version marks an important milestone in the journey we began
quite a few years ago.
Now, it is time for us to begin another journey to bring remote access to the cloud era. We have
created Azure Active Directory Application Proxy as another tool for customers to publish
applications in cloud-based solutions. Fortunately, Web Application Proxy in Windows Server and
Azure Active Directory Application Proxy share a lot of code. More than that, they share the same
concepts and perception of remote access and how to make it simple to deploy and easy to
maintain.
75 CHAPTER 2 | Software-defined datacenter