Updated: 10 September 2013
Updated: 15 July 2013
- I have heard from a member of the Web Application Proxy product group who said there is a bug in the Preview version that prevents Outlook Anywhere from working. They say it will be fixed in the RTM version
- Lync 2013 and Office Web Apps 2013 have been tested and work with some configuration changes. See https://blog.kloud.com.au/2013/07/15/publish-lync-2013-with-2012-r2-preview-web-application-proxy/
- ActiveSync does not support SNI so a default binding needs to be set on the Web Application Proxy as per the post above to make it work
- Clarification about ADFS being a hard requirement for the Web Application Proxy, even if only doing pass-through
- Clarification about modifying published applications
- Clarification about case sensitivity
The announcement from Microsoft TechEd North America early in June that got me really interested was the Windows 2012 R2 Web Application Proxy which was described as:
Web Application Proxy – The Web Application Proxy is a new role service in the Windows Server Remote Access role. It provides the ability to publish access to corporate resources, and enforce multi-factor authentication as well as apply conditional access policies to verify both the user’s identity and the device they are using resources, and enforce multi-factor authentication as well as verify the device being used before access is granted.
The Web Application Proxy is a reverse proxy and ADFS (Active Directory Federation Services) Proxy that also provides functionality like Workplace Join for Windows 8.1 using the Device Registration Service (DRS). I have a particular interest in the reverse proxy side having done a lot of work with UAG lately which makes me miss TMG! As discussed in my previous blog Publish Lync 2013 Including Mobility and Office Web Apps with UAG 2010, with TMG disappearing the only Microsoft product (other than IIS with ARR) with reverse proxy functionality is Microsoft Forefront UAG (Unified Access Gateway).
UAG development seemed to have slowed down and the latest Service Pack added support for Exchange 2013 and SharePoint 2013 but not even Lync 2013 that came out at the same time. No word has been heard about any future development and with people like Erez Ben Ari (Ben Ari on TechNet) moving to the IIS team it seems like the writing is on the wall for Microsoft’s Forefront TMG and UAG products. UAG is a very powerful product but is hamstrung by its legacy roots in e-Gap and IAG and reliance on TMG underneath. TMG is not supported on Windows 2012 so if it was to move forward a total rewrite would have been needed.
In this blog I cover a bit about the Web Application Proxy and show how to configure ADFS, the Web Application Proxy and publish a claims-aware test application. I also did some testing with publishing Exchange 2013 to see how it worked.
TechEd Sessions and Documentation about Web Application Proxy
A session at TechEd North America titled Enable Work from Anywhere without Losing Sleep: Remote Access with the Web Application Proxy and VPN Solutions showed off some of the functionality (video and slides available at the link) and the same session at TechEd Europe last week WCA-B333 came out with a lot more information that I only saw after I started testing unfortunately. There is now a single TechNet page dedicated to the Web Application Proxy http://technet.microsoft.com/en-us/library/dn280944.aspx
Web Application Proxy Functionality
The Web Application Proxy (WAP) is a Role Service under the Remote Access role of Windows 2012 which also includes DirectAccess, VPN and routing services. It can provide simple reverse proxy functionality using ‘Pass-through’ where no preauthentication is performed, or provide Active Directory Federation Services (AD FS or ADFS) authentication by performing the ADFS proxy function. Note that even in Pass-through mode, WAP needs a Windows Server 2012 R2 Preview ADFS farm and must be setup as an ADFS Proxy. Without ADFS you can’t even complete the configuration wizard. Pass-through and ADFS federation to claims aware applications can be performed like previous AD FS proxies as a workgroup machine in the DMZ.
The reverse proxy functionality that seems like it could be a TMG/UAG replacement is the ability for the WAP to provide preauthentication for non-claims aware backend applications. It takes ADFS authentication and initiates a new session to the backend server providing Single Sign On (SSO) across multiple backend applications. This was possible with UAG by modifying applications to use the Claims to Windows Token Service (C2WTS) as described in Access OWA with ADFS, but the promise of this new functionality is that no modification is required on the backend service.
The catch in this scenario is that the WAP can only provide preauthentication and backend authentication to non-claims aware applications published with Integrated Windows Authentication (IWA) using Kerberos. No IWA with NTLM or basic authentication support. NTLM and basic are supported in Pass-through mode only. So this is not a full UAG/TMG replacement for applications such as Exchange that typically would have preauthentication performed by the reverse proxy. Slide 9 from the Europe WCA-B333 session mentioned above, shows the preauthentication support.
In my testing though, it wasn’t as simple as this as NTLM and Basic did not work for rich clients – even in pass-through mode (Update: for ActiveSync this is fixed by adding a default SSL binding as ActiveSync does not support SNI) . Slide 40 on the same presentation states that UAG will still be supported until 2015. Additionally it says that the Web Application Proxy is ‘part of a broader BYO Access platform alongside AD, AD FS, Intune’ and ‘We are not building all of UAG functionality into Windows Server’, so it looks like Web Application Proxy may not be a total replacement for UAG.
Exchange 2013 Testing
There is very little documentation right now for the Web Application Proxy so the following are my observations and assumptions based on testing Windows Server 2012 R2 Preview in Windows Azure. That meant I could only have a single network card (a restriction of Azure) and I don’t know if that would change any functionality (as it would for TMG and UAG).
ADFS and KCD Requirements
The first important thing to note is that any preauthentication or ADFS proxy functionality requires Windows Server 2012 R2 ADFS on the backend. So for anything other than Pass-through, ADFS is a hard dependency. It was mentioned that the recommendation now is to run ADFS on a domain controller and ADFS seems to be taking over as the primary authentication mechanism for all Windows applications. Additionally a schema upgrade will be required to support all of the device registration functionality.
The second important thing to know is that in order to do preauthentication to backend applications, the WAP must be domain joined as Kerberos Constrained Delegation (KCD) is required. In the past ADFS proxies were not domain joined and the WAP can act the same way as long as KCD is not needed.
Setup a Domain Controller and add the ADFS role. Add a ‘Non-Claims-Aware Relying Party Trust’ for the Exchange CAS or CAS Array as can be seen below.
For the Issuance Authorization Rules, either ‘Permit All Users’ or you can limit who can authenticate through ADFS (and the Web Application Proxy) using Active Directory attributes. In this example I have created an AD group that allows access through the WAP. In the Issuance Authorization Rules, specify ‘Permit or Deny Users Based on an Incoming Claim’, specify ‘Group SID’ and select the relevant group. This allow the full flexibility of ADFS claims rules which can include specifying IP subnets, whether people are coming through the ADFS Proxy and many more.
Setup Web Application Proxy
Join the computer to the domain and install the Remote Access Role, and the Web Application Proxy Role Service.
Import the ADFS public certificate and any other certificates required for publishing. As with Server 2012, 2012 R2 supports Server Name Indication (SNI) which was covered previously on the Kloud blog An Overview of Server Name Indication (SNI) and Creating an IIS SNI Web SSL Binding Using PowerShell in Windows Server 2012. This allows multiple certificates to be used on a single IP and port combination, which is a great improvement over TMG and UAG.
Start the Web Application Proxy configuration wizard and setup the server as an ADFS proxy.
Publish an ‘Active Directory Federation Services (AD FS)’ application
Specify the Relying Party from the list of enabled Relying Parties configured on the on-premise domain joined ADFS farm server.
Setup the external and internal URLs and SPN for the internal web server. The publishing can either be a specific path or the whole server, however unlike TMG there is no ordering of applications so if you publish a whole server you cannot add a sub path as a higher rule. In this case I have published Exchange OWA and ECP as separate applications.
Note the warning at the top about the external and internal URLs not matching. That help topic is not live so I do not know what problems can arise, but this is probably for applications like SharePoint 2013 with Host Name Site Collections that require the external and internal URLs to match. And this is where you see the benefit of a modern reverse proxy – it shows you the PowerShell commands to create the application. Also make sure to add the trailing ‘/’ on both the external and internal URLs or it will complain.
For the ECP application I can create it with PowerShell:
Add-WebApplicationProxyApplication -BackendServerAuthenticationSpn 'http/marc-exchange1.marc.kloud.com.au' -BackendServerUrl 'https://marc-exchange1.marc.kloud.com.au/ecp/' -ExternalCertificateThumbprint 'F7F6B300FE4D569FD598E1C9722571CF9AD780DD' -ExternalUrl 'https://mail.marc.kloud.com.au/ecp/' -Name 'Exchange ECP' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'Exchange'
The final task is to setup KCD to allow the WAP to impersonate the user and obtain a Kerberos ticket to access the Exchange CAS. This is done by editing the WAP computer object and allowing delegation to the Exchange CAS SPN, or CAS Array Alternate Service Account user or computer object. A PowerShell function for this is provided in my previous blog post Outlook Anywhere NTLM SSO with UAG 2010 KCD
Testing Web Clients
Browse to the OWA URL e.g. https://mail.marc.kloud.com.au/owa/ which redirects to
Logging in with a domain user who is not a member of the ‘WAP Allowed’ group gives a friendly error:
While a user who is a member of the group gets OWA
Testing Rich Clients
In order to test Outlook Anywhere and ActiveSync rich clients, instead of creating separate applications for RPC, OAB, Autodiscover and Microsoft-Server-ActiveSync applications I published the whole server https://mail.marc.kloud.com.au/ as a test. This meant that Outlook couldn’t even get autodiscover as it doesn’t understand ADFS authentication. So back to separate applications and added autodiscover and RPC for Outlook Anywhere as Pass-through applications
This allowed a new Outlook profile autodiscover to work but Outlook just hangs on the ‘Logging on to the mail server’ for a few minutes and fails to connect.
I tried to change the Exchange internal and external URLs to be same to make sure the lack of body rewriting in WAP wasn’t causing the problem. I published the root of the server https://mail.marc.kloud.com.au/ and autodiscover https://autodiscover.marc.kloud.com.au/ in Pass-through mode but still could not get Outlook Anywhere or ActiveSync to work initially (Update: ActiveSync does not support SNI, so in order to make it work a default SSL binding must be added as mentioned in my post about Lync Publish Lync 2013 with 2012 R2 Preview Web Application Proxy). Possibly this is something in my configuration as according to the slide above, NTLM and Basic authentication should just work in Pass-through mode. If somebody else gets Outlook Anywhere to work, please let me know. (Update: according to a member of the Web Application Proxy product group there is a bug in the Preview version that prevents Outlook Anywhere from working. They say it will be fixed in the RTM version).
Testing Claims Aware Applications
Just to round out the testing, I used the WIF SDK 3.5 sample claims app ‘PassiveRedirectBasedClaimsAwareWebApp’ and configured it on a Windows 2012 R2 server using the process described in the ADFS and SSO lab setup guide. Create the Relying Party Trust as described in the documentation.
On the Web Application Proxy, add an ADFS preauthenticated application based on the ‘Claims App’ RP and configure the external and internal URLs
The end result is the published application:
Logging on from an external client shows the claims that the client has in the ADFS security token.
Opening other ADFS preauthenticated applications provides SSO as the client has a valid ADFS cookie and a valid Web Application Proxy cookie.
This is a preview release that is probably 6 months out from final release, so many things may change before RTM. With very little documentation I am guessing my way through some of the scenarios and configuration, so don’t take this a final analysis of the product.
- Single server for ADFS Proxy, Reverse Proxy, DirectAccess and VPN
- Totally PowerShell enabled and integrated into Windows
- Server Name Indication (SNI) support to provide a single ‘listener’ with multiple certificates
- Not based on IIS
- Stateless server with centralised ADFS configuration
- Provides new solutions like Workplace Join to enable work from anywhere and long term persistent SSO for authenticated and authorised devices
- Multi Factor Authentication (MFA) looks easy to define, but I couldn’t test it now
- Windows 2012 R2 Preview ADFS farm is required to install Web Application Proxy
- Cannot be an ADFS proxy for a previous ADFS version
- Non-SNI compatible clients like Lync mobile and Exchange ActiveSync require additional configuration on the Web Application Proxy to support them
- Case sensitive and requires trailing / for path based application publishing. https://mail.marc.kloud.com.au/owa/ does not equal https://mail.marc.kloud.com.au/OWA/ This isn’t an issue if you publish the root of the server. This is consistent with the web standards and Unix/Linux web servers that are case sensitive. It is a departure from IIS and TMG which do not care about case
The Bad aka ‘Hopefully will be added or fixed’
- No Basic or NTLM preauthentication
- Hard requirement on ADFS, even if only doing Pass-through
- Pass-through not allowing Outlook Anywhere to work – may just be me!
- No SSO for non-ADFS published applications. Pass-through applications each do their own authentication
- No ability to edit published application on the WAP server in the GUI. This can be done from PowerShell only. See http://technet.microsoft.com/en-us/library/dn283404
- No external HTTP to HTTPS redirect, or HTTP publishing
- Descoped the full URL translation like IIS ARR can do in this release. Header translation only, not body translation
- Exchange Outlook Anywhere is not supported with preauthentication. Planned to support in a future version
- No built in outbound load balancing to the backend servers so it requires a load balancer. TMG and UAG can provide this currently even if it isn’t used much. This support would remove a barrier to entry for some smaller companies
I would also like to see the ability in the console and WAP PowerShell cmdlets to set a default SSL binding certificate for non-SNI supported browsers so it doesn’t have to be done via netsh.