New in Windows Server 10 Web Application Proxy

• Author
• Recent Posts

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

Latest posts by Paul Schnackenburg (see all)

• Azure Sentinel—A real-world example - Tue, Oct 12 2021
• Deploying Windows Hello for Business - Wed, Aug 4 2021
• Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021

This Remote Access server role, first introduced in Windows Server 2012 R2, is in many ways a replacement for Forefront Unified Access Gateway (UAG), a product that Microsoft killed off in late 2013. Compared to UAG, WAP is much easier to deploy, and it’s built for today’s hybrid cloud world. WAP allows you to securely publish internal applications for remote access and works with Active Directory Federation Services (AD FS). Unlike traditional VPN solutions, only applications that you specify are available through WAP.

The fundamentals of WAP

Many IT professionals I talk to are unfamiliar with WAP, so let’s cover some basics so you can see why Microsoft is serious about improving this technology in the next version of Windows.

WAP lives in your DMZ. Because it’s the only server that needs to live there (your actual application servers live in the internal network), security is improved. WAP servers store their configuration on AD FS servers; hence, you can scale out and provide redundancy simply by adding more WAP servers. WAP is also an AD FS proxy (starting with 2012 R2, it has replaced that role) in that it listens to the same endpoints as AD FS, thus receiving traffic from federation clients on the Internet, which it then forwards to your internal AD FS servers and then relays responses back to the clients. This also improves security because your AD FS servers aren’t exposed to the Internet.

Installing Web Application Proxy

The version of WAP in Windows Server 10 will be certified to work with Lync Server. A new feature is HTTP-to-HTTPS redirection; if a user types HTTP instead of HTTPS for an address, the user is automatically redirected to the secure site. It is possible to achieve this in 2012 R2, but it requires you to install IIS and do a bit of configuration. Now, it’s just a check box in the UI.

Publishing an internal application

The biggest request the product team had based on the Windows Server 2012 R2 release was to support Exchange Active Sync (EAS) with pre-authentication—something that’s now in the Technical Preview. MSOFBA is how Office clients authenticate against SharePoint; this is also supported now.

OAuth2 is going to be fully supported as well. The current version has some limitations; full OAuth2 support will be a boon, particularly for mobile application implementations. Another new feature is wildcard publishing, making it easier to work with multiple sandboxed sites in SharePoint 2013. This also makes it possible to publish applications in bulk instead of having to do them one by one. Finally, you can publish HTTP applications, which, of course, isn’t secure unless the application provides some other method of security.

Publishing an internal application’s URL settings

If you have to troubleshoot WAP, there was an excellent session at TechEd Europe. Another new feature should help you out. In Event Viewer > Applications and services > Microsoft > Windows Web Application Proxy, you can see Administrative events (as in the current version); however, if you select View – Show Analytics and Debug logs, another node with session information is displayed. This information makes it much easier to find out what’s going on with individual sessions.

Azure Application Proxy

Although it’s not a new technology in Windows Server vNext, I would be remiss if I didn’t point out that a new service in Azure was just announced at TechEd Europe 2014: Azure Application Proxy (AAP).

Basically the same functionality described above for the on-premises version is available as a service in Azure. The functionality works with Azure Active Directory Premium, giving you an Access Panel where users can access Microsoft SaaS applications, as well as more than 2,600 third-party SaaS applications, in a controlled, single-sign-on manner.

Web applications that are hosted inside your company can be linked to AAP with a lightweight connector agent, requiring no extra firewall ports to be opened and no special DNS or security configuration. These apps will then appear on the Access Panel for authenticated users.

This feature is in preview. As such, it’s missing some features to bring it up to par with WAP, such as support for Kerberos–based authentication, a console to show the status of connectors, in-depth auditing, and support for connectors for the same application hosted in different geographical locations. Microsoft is expecting to add these features before AAP becomes generally available.

For more information about what’s going on with WAP and AAP, check out the team’s blog.

Conclusion

The world of business IT is changing rapidly and becoming (even more) interconnected and more cloud-friendly and old problems are finding new solutions. WAP is a very interesting technology that enables you to give your users access to internal Line of Business applications on any device with a browser (BYOD anyone?) in a secure manner. It’s another tool in the toolbox for a differentiated IT professional looking for mobility solutions to business problems.

Next in this series, you'll read what's new in Windows Server 10 Remote Desktop Services (RDS) .