loading...

Windows Server 2019 – Latest improvements to WAP

How to Create MySQL Users Accounts and Grant Privileges

Web Application Proxy was introduced in Server 2012 R2, and had many improvements when Windows Server 2016 was released. There have been no major modifications since that time, but it is still important to point out the latest benefits that have been rolled into this feature, to show that it is still learning to do new things. The following are some of the improvements that have been made if you haven’t taken a look at WAP since its first iteration.

Preauthentication for HTTP Basic

There are two different ways that users can authenticate to applications that are being published by Web Application Proxypreauthentication or pass-thru authentication. When publishing an application with preauthentication, this means that users will have to stop by the AD FS interface to authenticate themselves before they are allowed through to the web application itself. In my eyes, preauthentication is a critical component to any reverse-proxy, and I would have to be stuck between a rock and a hard place in order to externally publish an application that did not require preauthentication. However, the second option is to do pass-thru authentication, and it does exactly that. When you publish access to an application and choose pass-thru authentication, all WAP is doing is shuttling the packets from the internet to the application server. Users are able to get to the web application without authentication, so in theory, anyone can hit the front website of your application. From there, the application itself will likely require the user to authenticate, but there is no man-in-the-middle protection happening; that web application is available for the public to view. As you can tell, I do not recommend taking this route.

We already know that WAP can preauthenticate web applications, but the original version could not do any form of preauthentication on HTTP Basic applications, such as when a company wanted to publish access to Exchange ActiveSync. This inability leaves ActiveSync a little bit too exposed to the outside world, and is a security risk. Thankfully, this changed in Windows Server 2016you can now preauthenticate traffic streams that are using HTTP Basic.

HTTP to HTTPS redirection

Users don’t like going out of their way or wasting time by having to remember that they need to enter HTTPS:// in front of the URL when they access applications. They would rather just remember email.contoso.com. The inability of WAP to do HTTP to HTTPS redirection had been an annoyance and a hindrance to adoption, but that has since changed. Web Application Proxy now includes the capability for WAP itself to handle HTTP to HTTPS redirection, meaning that users do not need to type HTTPS into their browser address bar any longer; they can simply type in the DNS name of the site and let WAP handle the translations.

Client IP addresses forwarded to applications

In the reverse-proxy and SSLVPN world, we occasionally run across applications that require knowing what the client’s local IP address is. While this requirement doesn’t happen very often, and is typically segregated to what we would call legacy applications, it does still happen. When the backend application needs to know what the client’s IP address is, this presents a big challenge with reverse-proxy solutions. When the user’s traffic flows through WAP or any other reverse-proxy, it is similar to a NAT, where the source IP address information in these packets changes. The backend application server is unable to determine the client’s own IP address, and trouble ensues. Web Application Proxy now has the ability to propagate the client-side IP address through to the backend application server, alleviating this problem.

Publishing Remote Desktop Gateway

One of the items that UAG was commonly used for was publishing access to Remote Desktop Services. UAG was essentially its own Remote Desktop Gateway, which gave you the ability to publish access to RDSH servers, individual RDP connections to desktop computers, such as in a VDI implementation, and even access to RemoteApp applications. Unfortunately, WAP cannot do any of this, even in the new version, but the fact that they have added a little bit of functionality here means movement in the right direction is happening.

What has been improved regarding WAP and Remote Desktop is that you can now use WAP to publish access to the Remote Desktop Gateway server itself. Traditionally, a Remote Desktop Gateway sits on the edge of the network and connects external users through to internal Remote Desktop servers. Placing WAP in front of the RD Gateway allows stronger preauthentication for Remote Desktop services, and creates a bigger separation between the internal and external networks.

All of my fingers are crossed that we will continue to see improvements in this area, and that WAP can be expanded to handle traffic like Remote Desktop natively, without even needing a Remote Desktop Gateway in the mix.

Improved administrative console

The original version of WAP inside Windows Server 2012 R2 was best served using PowerShell to implement it. You can certainly still use PowerShell to create your publishing rules if you so choose, but the Remote Access Management Console has now been improved in terms of how it relates to the Web Application Proxy. Before you see it in the console, you need to make sure that the appropriate box was checked during the Remote Access role installation. If you did not select Web Application Proxy when you first installed that role, revisit the add/remove Roles function inside Server Manager in order to add WAP to this server:

Note that, while Web Application Proxy is a component of the same Remote Access role that houses DirectAccess and VPN, it is not recommended to run WAP alongside DA and VPN on the same server. As you already know, you can certainly co-host DA and VPN connections together, simultaneously on a single Remote Access Server. But once you make the foray into WAP, this should be a standalone component. Do not run WAP on a DA/VPN server, and do not run DA/VPN on a WAP server.

Now that we have added Web Application Proxy to our server, you can open up the Remote Access Management Console and see it listed inside the Configuration section. From here, you launch the Web Application Proxy Configuration Wizard and start walking through the steps to define your AD FS server, the certificates you are planning to use, and other criteria needed for the role:

Comments are closed.

loading...