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:
- Enable publishing and preauthentication for more apps
- 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.
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.