Introducing the next version of Web Application Proxy


As part of the bigger Windows announcement this week we are excited to share with you the abundance of additional functionality that has been added to Web Application Proxy and AD FS as part of Windows Server next version Technical Preview.

It has only been a year and a half since we exposed Web Application Proxy to the world in Windows Server 2012 R2 Preview. In this short time period it was deployed by many customers. Many Fortune 500 companies, Big Four accounting firms and also thousands of small companies and organizations from all over the world, have adopted Web Application Proxy.

We heard your praises that it is a robust architecture and the easiest reverse proxy to deploy. We tried to keep ourselves tuned to hear also the criticism and the requests for features you need. Over this year and a half we talked to dozens of customers that deployed the product and looked closely how we can help them get more value from their deployments.

We also talked to customers that are still using our legacy products, Forefront TMG and Forefront UAG that were announced as end-of-life and examined the barriers moving to Web Application Proxy.

At the end of this process we decided to focus on two themes:

  1. Enable publishing and preauthentication for more apps
  2. Ease the experience even more

We are eager to hear what you have to say about those new features. Please share with us your experience. It will help us improve the product towards the official release. We want to know how these features perform in your environment and if they satisfy your needs. You can use the Email Blog Author option on this page to contact us.

You can install the new Web Application Proxy first by downloading the Windows Server next version Technical Preview bits on a new machine or try it on Azure and then by adding the role service. We recommend installing it with Windows Server vNext AD FS, although some of the functionality will also work even when deploying it with Windows Serve 2012 R2 AD FS.

Our TechNet documentation has all the details on the new features. Here are the highlights:

 

HTTP Basic preauthentication – Secure ActiveSync traffic

In this release we are adding the capability to preauthenticate with AD FS protocols that are using HTTP Basic authentication where credentials are sent within the request and clients do not understand HTTP redirects or able to present login UI. For example, one of the most common protocols that is working like that is Exchange ActiveSync. With this addition, you can preauthenticate Exchange ActiveSync traffic with Web Applications Proxy.

When a request for a URL of application that is marked as HTTP Basic arrives, Web Application Proxy extracts the credentials from the request and sends this data to AD FS using a new AD FS endpoint. AD FS processes the request as it is doing for all authentication requests. If it is valid, it issues a token that is sent back. When Web Application Proxy receives a valid token from AD FS, it allows the traffic to be sent to the backend server. The token is cached by Web Application Proxy for future use to reduce the AD FS load.

This capability is on-top of the existing preauthentication methods that Web Application Proxy supports with AD FS that includes: Browsers, MSO-FBA for Office clients and OAuth2.

Here is a diagram describing this flow:

  

 

HTTP Basic preauthentication with certificates – Making ActiveSync even more secure

HTTP Basic will have an additional mode that would allow not only to preauthenticate the user but also to assure that the request is coming from a device that has gone through the process of workplace join and is registered using the device registration service (DRS). This is done by requiring incoming requests to present the workplace joined device certificate that was issued to them. This certificate is validated by AD FS using the same endpoint that is used to validate username and password.

This mode allows the ultimate security, making sure that the client presents proof of “what you know” (password) and “what you have” (device).

 

Wildcard domain publishing – new patterns and easier SharePoint 2013 apps publishing

We are adding the ability to publish not only a specific domain name but an entire sub-domain. This opens new opportunities for customer that want to publish sites in bulk and not one by one. For example, if all your apps are under http://*.apps.internal/, you can publish them using a single external domain like https://*.apps.contoso.com/.

This pattern is important when there is a need to publish SharePoint 2013 apps that uses a special sub-domain to all apps. In this case, only wildcard certificates would work as the specific apps domain may change over time.

 

HTTP publishing

In Windows Server 2012 R2, applications cannot be published with an external URL that is not HTTPS. This was done to assure that there is no leakage of user’s data. In current version we allow also using external address with HTTP.

HTTP publishing will be available only to applications that are not using preauthentication to assure that sensitive information will not leak.

 

HTTP to HTTPS redirection

We heard from many customers that when they publish applications using HTTPS, users should be able to access them even if they typed in their browser’s address bar the application HTTP URL with the same domain. By redirecting HTTP requests to the external URL of HTTPS applications we reduce the risk of server spoofing and improve the user experience.

In previous version, configuring this was complicated and required IIS installed side-by-side to Web Application Proxy. In the current version we are enabling this feature without installing IIS and with a single Boolean parameter or UI checkbox. Whenever this option is selected for HTTPS application, HTTP redirection will kick in.

Here is a sample configuration of both HTTP publishing and HTTP to HTTPS redirect:

 

Remote Desktop Gateway (RDG) publishing

Remote Desktop is a very common method to allow remote employees accessing legacy applications, usually rich applications that cannot be published using reverse proxies. In order to simplify the deployment experience for our customers, we have made a change in Web Application Proxy to enable publishing of Remote Desktop Gateway. This change allows RDG to pick up the session cookie that was used by RD Web Access so the RDP over HTTP traffic is authenticated.

This opens new opportunities as AD FS can be utilized to perform preauthentication for Remote Desktop access using all of its capabilities such as Multi-Factor Authentication and smartcards. For the users, it means that Remote Desktop authentication has the same experience as their Web applications. It also simplifies the admin experience by having a single entry point to the system and a single authentication and authorization mechanism across all applications.

This change was made available also to customers using Web Application Proxy on Windows Server 2012 R2 as part of the August 2014 update package.

Here is a typical topology of such deployment:

 

Improved logging for better audit and easier troubleshooting

Logging is important aspect of Web Application Proxy and in this release we wanted to make them more comprehensive. In order to do it without compromising performance, we added many more events as analytics and debug logs. Other than these new events, we also added more information to the existing admin events.

 

Administrator UI Enhancements

We LOVE PowerShell. But, we hear from many customers that they also love our admin UI and would like to use it for more scenarios. In this release we are improving the UI and provide more options that were PowerShell-only in Windows Server 2012 R2. We have added the ability to edit the applications directly in the UI.  This will allow administrators to review their configuration settings without having to go to PowerShell.

All of the new features described above are available on both our administrative console UI and using PowerShell. As usual, you can use the console to generate PowerShell commands and run them later.

 

Propagate client IP address to backend application

Many customers told us that for troubleshooting and auditing purposes, they want their backend applications to be aware of the original client IP address. To solve this, Web Application Proxy will add now to every request X-Forwarded-For header that includes this address. If this header already exist, we will concatenate the client IP to this header.

 

 

 

The list of new features is long. Our team worked hard on delivering the new capabilities while assuring we continue our track record of high quality and security standards. Now we are waiting to hear from you. Please let us know not only on things that do not work for you but also on the things that are working fine. We have long road ahead of us to bring this into the final release and maybe even to add more capabilities.

In parallel to evolving Web Application Proxy as traditional reverse proxy, we are investing in making Azure Active Directory Application Proxy an innovative service that would allow customer to move to new cloud patterns. Most of these capabilities will be available on both solutions enabling customers to select the type of deployment.

 

Comments (43)

  1. MeirM says:

    @MHengstler: We are not aware to such failure. We would like to investigate this further. Please contact us at aadapfeedback @ microsoft.com.

  2. MeirM says:

    @Michael: The topology that you are describing is robust and secure. The main advantages of using Web Application Proxy with RDG is to have a single point of entry to the organization and a single place (ADFS) to do all authentication and authorization.
    ADFS also have more flexibility in the forms of multi-factor authentication. If you already deployed RDG with multi-factor authentication there is no benefit of adding Web Application Proxy on-top.

  3. MeirM says:

    @Dmitrii: You can use the new EnableHTTPRedirect application PowerShell parameter or just use the textbox in the UI.

  4. Mathieu Ait Azzouzene says:

    Outlook Anywhere pre-auth? Sounds good for my client, but will it be availlaible under Server 2012 R2 or only under vnext?

  5. MHengstler says:

    I tried to set up a scenario with basic authentication – unfortunately AppProxy.exe keeps crashing as soon as I initiate traffic to WAP – even if it’s to an application with pass-through configured. Something known?
    Regards
    Markus

  6. HI,
    great to see that some of the UAG functionality is making its way back. Without having looked at the preview, is it possible to do template based publishing? E.g. I want to publish Sharepoint or Exchange related services. Furthermore, will it be possible to
    publish multiple virtual directories in one rule? In other words, publish /vdir1/* and /vdir2/*. I other words, I don’t have to expose the entire namespace.

  7. Excellent article. Thank you.

  8. Anonymous says:

    > Web Application Proxy will add now to every request X-Forwarded-For header that includes this address.

    I have been unable to observe this header in practice and can find no documentation on configuring it.

    How can the Request header, be validated or configured ?

    Thanks
    – Mark

  9. Me says:

    sounds good
    Toda

  10. Konnan says:

    Hello MeirM,

    I was wondering if there is anything about having multiple different portals in the next version of WAP/ADFS instead of customizing OnLoad.js ?
    We would like to have a custom portal per application, since we publish applications for several companies, there’s different logos and different text to be put on the front portal page that you log on.
    We were doing that with ISA, but we are trying to replicate it in WAP/ADFS.
    I do not see a need for a full custom page, but just to be able to use current powershell commands but with several active themes at once instead of a single one, that would be nice.
    That way, we could have a different logo and a different text for each WAP/ADFS portal.
    I know we could put a different ADFS/WAP farm per application to have a different theme, but that’s really overkill and costly…

    Thank you very much !
    Konnan

  11. Jesper Ståhle says:

    Great stuff! Will Basic http pre-auth work with Exchange EWS the same way as well?

  12. Anonymous says:

    Endlich ist sie da, die in diversen Blogs von unterschiedlichen Spezialisten und durch Leaks untermauerte

  13. Jason says:

    Load balancing? Health check? HA? All functions from iis arr?

  14. jaydee says:

    Hi MeirM,

    great improvements. Here are some additional points from my wishlist:

    1. Centralized certificate store. I would expect certificates for published applications to be stored in ADFS storage and pushed to the WAP endpoints automatically (and not having to import them in all WAP local machine stores before publishing). This would
    also ease certificate replacement.

    2. Idle Timeout. Provide a means for the edge access token to timeout if a user is idle for a configurable time.

    3. Global logout. Possibility to globally logout from all published applications without the need to close the browser.

    4. Block selected paths of published applications. E.g.
    https://app.company.com/abc/ is published but block external access to
    https://app.company.com/abc/internalonly

    Thanks,
    JD

  15. Jason Bailey says:

    Hi, does the Workplace Join work with iOS Devices? I configured all of this up last weekend and couldn’t get ActiveSync to use the certificate that was installed on the device. Perhaps I need to reconfigure the type of certificate issued or something?

  16. Anonymous says:

    Hi everyone,
    We’re pleased to introduce our new guest blogger, Mark Grimes from Microsoft Consultancy

  17. Michel Matton says:

    If users are only accessing rdweb published apps, is there any benefit to adding this additional layer (WAP)? I’m currently using RD Gateway with iis client certificate mapping as a form of 2-factor authentication.

  18. PhilD' says:

    @Meir, I tried to open the Applications via RD Web Access through Web Application Proxy. I am able to use Federation Server to pre-authenticate and log into the Terminal Server successfully, however, it always failed when I open the application. is there
    a way to monitor or capture the application window?

    Thanks

  19. mz says:

    great features I was waiting for, any approx date of new relese?

  20. Chumley says:

    Nice additions. Would be really great if RADIUS could feature in there to complete the pre-authentication schemes.

  21. Passwords? says:

    Hello,
    When using ADFS HTTP Basic, should the password be the same in both account and resource forest?

  22. Dmitrii says:

    Hello Meir

    Could you point on some resource which explains in details how to actually configure HTTP to HTTPS redirection, please?

    Or probably you can explain it in brief, please?

    TechNet doesn’t have it.

    Thank you

  23. Dan Fink says:

    Has this new version been released yet? I’d love to set up HTTP – HTTPS Redirect, but I can’t find any other documentation on it beyond your blog post.

  24. Chuck Martin says:

    @MeirM How can I tell if the HTTP to HTTPS redirect feature exists on my 2012R2 server install? I have found no PowerShell CMD nor UI option to allow my publish applications to be redirected to the HTTPS site.
    Thanks for any or all help.

  25. Brian says:

    As Mathieu asked, will this be available for 2012 R2 or only under vNext? We need some of these features now. Thanks.

  26. Patric says:

    When you’re mentioning the August update for 2012R2 Wap to support RDG and RDWeb, are you talking about the HTTPOnly setting? ny hints on how to set this up?

  27. Anonymous says:

    Microsoft is the only vendor that offers both on-premises and cloud solutions for remote application

  28. Michael B. says:

    What about a way to deploy WAP without requiring ADFS? Not everyone needs or wants ADFS. I don’t see any practical way to deploy this in a single server environment. I was able to do that with ISA/TMG and with ARR. This seems like a step backwards. Or
    is there something I’ve missed?

  29. Jochen Froehlich says:

    I’m experiencing the same problem as Mark_A_Jones.
    My WAP proxies an IIS Website in Pass-Through Mode. Advancded Logging on the IIS shows no headers sent by the WAP.

    Any ideas?

    Cheers Jochen

  30. Jochen Froehlich says:

    Hi Lewis,
    i know how to use X-Forwarded-For header in IIS to log the original client IP. This works like a charm if a header is sent, but the WAP doesn’t send the X-Forwarded-For if I’m using it in pass trough mode. If I use ADFS istead of passthrough I see the header.

    So the question is: Why are there no header if I use Passtrough mode without the use of ADFS?

    Cheers Jochen

  31. Swamped Server says:

    I have the same question as Jochen Froehlich, Passthrough authentication seems to not be adding the header in correctly. I can’t see it in logging, wireshark, or a test web application.

  32. Jonathan Spigler says:

    Great article MeirM! Look forward to the enhancements especially the additional logging and auditing features.

    About to transition from UAG and TMG to WAP over the next couple months. One thing my client HEAVILY relies on is client certificate authentication (smart cards). I know one thing that was great with TMG and UAG was the client cert auth (or smart card auth)
    went over 443 along with all the other HTTPS traffic which lead you to only having to open 443 on your FW to your UAG or TMG servers. I know with WAP you are required to open 49443 on your external FW so clients can authenticate via client certificate or smart
    card. This is easily achievable on our end to open this up but I’m thinking about clients coming in from other network enclaves that may have that port blocked out bound (49443). Does MS have any plans to have this auth traffic run on the same port as the
    HTTPS traffic (443)?

  33. Anonymous says:

    tl;dr
    For CRM application proxying, load balancing and other magic like IP filtering, use Application

  34. Anonymous says:

    Microsoft is the only vendor that offers both on-premises and cloud solutions for remote application

  35. Anonymous says:

    This document provides an overview of the features and benefits of using Microsoft Web Application Proxy

  36. Anonymous says:

    Microsoft is the only vendor that offers both on-premises and cloud solutions for remote application

  37. Ghousullah says:

    How to get the latest version. Because we are in need of publishing http external urls without any certificates. Also please let me know is there any powershell commands to publish non-http urls.

    Thanks!!!

  38. Anonymous says:

    Microsoft is the only vendor that offers both on-premises and cloud solutions for remote application

  39. Steve Weary says:

    Hi MeirM

    Any news on websockets being supported by WAP? I believe it’s on the product road map but have not heard anything recent. Here’s hoping it is not too far off!

    Thanks

  40. John says:

    > > Web Application Proxy will add now to every request X-Forwarded-For header that includes this address.

    > I have been unable to observe this header in practice and can find no documentation on configuring it.

    I have the same problem: no X-Forwarded-For header found in trace with pass through authentication. I would really like to use this software, but we have a security requirement to retain the IP information. If WAP cannot be configured to log the original client IP, and it is being used for SSL offloading, how can I trace a request back to an IP if a forensic investigation is ever called for?

    Anyone have a work around?

  41. Andy says:

    @MeirM: we have got an existing rds setup in windows 2008r2, is it possible to use WAP & ADFS for external users and point to the existing setup (w2k8r2) without upgrading everything such as gateway, broker, session hosts?
    thanks

Skip to main content