loading...

Windows Server 2019 – Web Application Proxy

Installing an FTP server

DirectAccess and VPN are both great remote access technologies, and combining the two of them together can provide a complete remote access solution for your organization, without having to pay for or work with a third-party solution. Better still, in Windows Server 2019, there is yet another component of the Remote Access role available to use. This third piece of the remote access story is the Web Application Proxy (WAP). This is essentially a reverse-proxy mechanism, giving you the ability to take some HTTP and HTTPS applications that are hosted inside your corporate network, and publish them securely to the internet. Any of you who have been working with Microsoft technologies in the perimeter networking space over the last few years will probably recognize a product called Forefront Unified Access Gateway (UAG), which accomplished similar functionality. UAG was a comprehensive SSLVPN solution, also designed for publishing internal applications on the internet via SSL. It was considerably more powerful than a simple reverse-proxy, including components such as pre-authentication, SSTP VPN, and RDS gateway; DirectAccess itself could even be run through UAG.

If all of your mobile workers have access to launching either DirectAccess or VPN, then you probably don’t have any use for WAP. However, with the growing cloud mentality, it is quite common for users to expect that they can open up a web browser from any computer, anywhere, and gain access to some of their applications. Document access is now often provided by web services such as SharePoint. Email access can be had remotely, from any computer, by tapping into Outlook Web Access.

So many applications and so much data can be accessed through only a web browser, and this enables employees to access this data without needing to establish a full-blown corporate tunnel such as a VPN. So what is the real-world use case for WAP? Home computers that you do not want to be VPN-connected. This way, you don’t have to worry as much about the health and status of the home or user-owned computers, since the only interaction they have with your company is through the web browser. This limits the potential for sinister activity to flow into your network from these computers. As you can see, a technology such as WAP does certainly have its place in the remote access market.

I have hopes that, over time, WAP will continue to be improved, and that will enable it to be a true replacement for UAG. UAG ran on Windows Server 2008 R2, and has now been officially discontinued as a Microsoft product. The closest solution Microsoft now has to UAG is the WAP role. It is not yet nearly as comprehensive, but they are working on improving it. Currently, WAP is useful for publishing access to simple web applications. You can also publish access to rich clients that use basic HTTP authentication, such as Exchange ActiveSync. Also included is the ability to publish data to clients that use MSOFBA, such as when users try to pull down corporate data from their Word or Excel applications running on the local computer.

WAP can be used to reverse-proxy (publish) remote access to things such as Exchange and SharePoint environments. This is no small thing, as these are technologies that almost everyone uses, so it can certainly be beneficial to your company to implement WAP for publishing secure access to these resources; it’s certainly better than NATing directly to your Exchange server.

WAP as AD FS Proxy

Another useful way in which you can utilize a WAP server is when setting up Active Directory Federation Services (AD FS) in your network (this is perhaps the most common use for WAP right now). AD FS is a technology designed to enable single sign-on for users and federation with other companies, and so it involves taking traffic coming in from the internet into your internal network. In the past, there was a Windows Server role component that accompanied AD FS, called the AD FS Proxy. In the latest versions of AD FS, this separate role no longer exists, and has been replaced by the Web Application Proxy component of the Remote Access role. This better unifies the remote access solution, bringing your inbound AD FS traffic through the official Remote Access Server, rather than needing a separate AD FS Proxy server. Anyone implementing outward-facing AD FS in their environments will likely find themselves required to deploy WAP at some point.

Comments are closed.

loading...