Secure Extranet Publication of Exchange 2010 OWA via Server 2012 R2 Web Application Proxy
Hello all, Jesse Esquivel here again with a post about publishing Exchange 2010 via Server 2012 R2 Web Application Proxy (WAP). Before we get started on this post I wanted to take a minute to talk about reverse proxy functionality and where Microsoft is headed with this technology. As you know, Threat Management Gateway (TMG) and Unified Access Gateway (UAG) have a definitive end of life. Some folks have looked into Internet Information Services Application Request Routing or ARR. ARR is a web farm extension meant for publishing web sites, however ARR does not do pre-authentication, there are no PowerShell cmdlets, no high availability, and there is no ongoing investment in ARR. We now have a new product that is included as a server role in Windows Server 2012 R2 – the Web Application Proxy or WAP. WAP is a reverse proxy solution that relies on ADFS for publication of both claims aware and non-claims aware web applications. WAP is built for current and future web protocols; it understands ADFS, claims, OAUTH, it can also do protocol transition, and Kerberos constrained delegation. Specifically (and applicable to this post) protocol transition and KCD are required for smart card only authentication (authN) into extranet published Kerberos enabled web applications – one of the same functionality sets that TMG and UAG provided. This means that WAP can publish claims aware AND non-claims aware web applications using smart card only authN.
Though this article is specific to publishing Exchange 2010 as an illustration/example Any Kerberos aware web application can be published in this fashion using WAP.
Many customers are currently evaluating reverse proxy products for publishing things like Exchange, and other web applications for various reasons. Some customers are moving off of Internet Security and Acceleration (ISA) server for the first time. Some customers are publishing a new web application for the first time and want to publish with something that does not have a definitive end of life like TMG or UAG. Some customers may want to move off of TMG or UAG in preparation for the sunset of these products. Whatever the reasoning, WAP is a new Microsoft solution that is capable of doing reverse proxy for claims aware and non-claims aware web applications and offers forms based and certificate based pre-authentication as well as pass through authentication. Microsoft is committed to WAP and we plan to continue its evolution and add functionality over time - WAP is the strategic choice for application publishing from Microsoft. So if you’ve heard of it or been considering it, now is the time to get it in your labs and start evaluating it!
This post about publication of Outlook Web App (OWA) is targeted to folks that must use smart card only authentication for external access into OWA, or any other Kerberos aware web application for that matter. For lab use and discussion - today I’m writing to you about a high level overview of securely publishing Exchange 2010 OWA with smart card authN using Kerberos constrained delegation (KCD) via this new server role that is available in Server 2012 R2. In order to securely publish OWA we will use Server 2012 R2 Web Application Proxy, and Server 2012 R2 Active Directory Federations Services (ADFS 3.0). ADFS is a hard requirement for publishing via WAP. WAP and Server 2012 R2 ADFS provide a seamless and secure extranet publishing solution that can use strong two factor smart card authentication for OWA.
Overview
Here you’ll find an overview of a basic publication setup. We have the WAP box that sits in a DMZ construct, ADFS 3.0, a domain controller, and an exchange 2010 Client Access Server (CAS) array. All servers are joined to the same Active Directory domain.
Pre-Requisites
Couple of quick ones here (this is not an exhaustive list). Server 2012 R2 ADFS (3.0) is required.
DNS
· An external DNS record for the security token service running as an ADFS proxy service on the web application proxy will need to be created so internet clients can resolve the federation proxy service. The ADFS proxy service is integrated into the WAP server role.
· The external DNS record should resolve to the external firewall and traffic should be forwarded to the WAP server, which also acts as an ADFS proxy.
· An internal DNS record for the security token service running on the ADFS server will need to be created so that internal clients can resolve the federation service.
· If the internal domain DNS name and the external DNS A record of the federation service do not match, you will need to use a split brain DNS setup configuration, which is out of scope for this blog post.
· Optionally if internal ADFS use is not required you can use a host file entry on the Web Application Proxy server that has the federation service name and the IP of the internal ADFS server.
WAP
· The WAP server must be joined to a domain that is trusted by the Exchange CAS boxes for KCD to function, the domain may even belong to a different forest as long as cross-forest KCD enabled (2012 DCs required).
· The WAP server must be able to get client certificate revocation information via ocsp or crl fetch, both are port 80 so modify your firewall rules accordingly.
· Internal communications – the WAP server must be able to talk a DC in the domain it is joined to, the CAS array, and the ADFS box so allow communication to these boxes or restrict ports accordingly.
· WAP listens on port 443 (SSL) for incoming client connections for published web applications.
· If requiring smart card authentication into Exchange 2010 (or any published web app) WAP also listens on port 49443, which is TLS client certificate authentication. Both of these ports must be opened/forwarded on your external firewall.
Certificates
· You’ll need the SSL cert for your OWA URL. Since users will be hitting the WAP box for the web site to be served the OWA SSL cert will need to be imported on the WAP box.
· You will also need an SSL cert for the federation service. This certificate should have its private key marked as exportable, as it will need to be imported onto the WAP box for the ADFS proxy component which is integrated with the WAP role.
· The OWA and the federation service certificates must be trusted by internet clients so typically you will want an SSL cert for each of these from public certificate authorities.
· Note: Server 2012 R2 ADFS 3.0 does not support the use of a CNG key, so you must create the certificate signing request with a legacy key.
Installation and Configuration
As it is a hard requirement for WAP, ADFS 3.0 is up first! ADFS 3.0 installation was covered here, so you can use that to get started. The federation service name for this solution is sts.treyresearch.com
Note: When configuring ADFS 3.0 for the first time the federation Service Name field CANNOT be the same as the DNS name of the ADFS server. A good example, and used here is:
· Federations Service Name: sts.treyresearch.com
· ADFS Server Name: adfs1.treyresearch.com
ADFS should now be installed and configured. Since Exchange 2010 is a non-claims aware app and we are using smart card authN/KCD we need to create an ADFS 3.0 Non Claims Aware Relying part trust. Open the ADFS management MMC snap in. In the left pane right click Relying party trust and click “Add Non-claims-Aware Relying Party Trust…”
At the welcome screen click start, then at the specify display name screen, type a display name for the trust. At the configure identifiers screen type at least one trust identifier, use something that you can easily identify and is related to what you are doing, here I used the example URL and swapped the dns name to match my mail URL. This way when I look at the trust identifier (now or troubleshooting later) I know that this identifies the non-claims aware relying party trust for OWA. Click add, then click next.
At the “Configure Multifactor Authentication Now?” screen click “I do not want to configure multi-factor authentication settings…” and click next.
At the ready to add trust screen click next. At the completion screen check the following box and click close.
At the Issuance Authorization Rules screen click Add Rule at the bottom:
At the rule type screen select permit all users, click next, and then click Finish:
That wraps it up for the ADFS 3.0 part. Next we will go into configuring the WAP role.
Server 2012 R2 Web Application Proxy
Since WAP installation and configuration is covered here, I won’t go into it. Now that WAP is installed and configured with our federation service name of sts.treyresearch.com, and has the sts.treyresearch.com federation service certificate imported and configured for the ADFS proxy component we’re ready to move on, so let’s take a minute to review. We have the ADFS 3.0 box up, the federation service configured, and the non-claims aware relying party trust is configured. The WAP server is also installed and configured.
It’s time to publish Exchange 2010 OWA via WAP. But first you must be aware of the following…In order for Kerberos constrained delegation to function against an array of Exchange 2010 CAS you must configure all of the array members to use an alternate service account (ASA) credential for Kerberos and set a service principal name on the ASA. Please see the following articles to set the ASA on the CAS array members:
https://technet.microsoft.com/en-us/library/ff808312(v=exchg.141).aspx
You must do this before publishing OWA via WAP as you will need the SPN that is used on the ASA credential. Once the ASA is configured on all CAS array members (as per the above link) proceed with publishing OWA via the WAP server. When configuring the ASA credential above make note of the SPN configured for the CAS ASA account as you will need it. For example here are the SPNs added in this setup:
On the WAP server open the remote access configuration manager by navigating to the start screen and typing “remote access.” In the right pane click Publish:
At the welcome screen click next. At the Preauthentication screen select ADFS and click next:
At the relying party trust select the Non Claims Aware RP trust that you created on the ADFS 3.0 server and click next:
Here’s where the magic happens, AKA where the rubber meets the road. At the publishing settings screen, select the SSL certificate for your published web application and configure the options shown. If you haven’t already, go ahead and import the web applications (OWAs) certificate with private key into the WAP servers personal or ‘My’ store.
Note: It’s best to import the cert and private key of your OWA cert beforehand here as well, this way you can simply select it in the drop down arrow when prompted. The web site SSL certificate is required on the WAP server (since it is a reverse proxy) as it will be serving the web page to the internet client (the CAS server does not serve it directly).
If you are publishing an Exchange CAS Array enter the HTTP SPN configured when the ASA was set on all CAS array members *you remembered this from above, right* ; )
In order to take advantage of the CAS Array load balancing (NLB or HLB flavors) you’ll want to use the internal DNS FQDN of the CAS array VIP for the backend server URL field. Click next and then click Publish. You will then see the published application in the remote access console.
Note: If publishing Exchange OWA you will also need to publish the ecp directory following the same guidelines above. It’s best to avoid publishing the entire server but instead publishing the URLs granularly.
Ok, now that we have OWA published, let’s configure KCD so that the WAP server can authenticate to the CAS array on behalf of the user. KCD is necessary to protocol transition a smart card credential to a Kerberos token. This step can be done before or after publishing the application via WAP, so long as the SPN has already been set on the CAS array.
Login to one of your domain controllers (or via RSAT) and locate the WAP computer object in Active Directory Users and Computers.
· Right click the object and click properties.
· Select the delegation tab, click add and select the computer or user object that has the registered SPN for your web application.
· In this case we are publishing Exchange 2010 OWA so we select the user or computer object that was used as the alternate service account (ASA) where the HTTP SPN was registered.
· Select “Trust this computer for delegation to specified services only,” and “use any authentication protocol”
Click OK to commit the changes to the WAP server computer object. Yes, that’s it. That’s all you have to do for KCD. So, we’ve installed and configured ADFS and WAP. Published Exchange 2010 OWA/ECP via WAP, and configured KCD for the WAP box. All this with smart card only authN into OWA. I have this solution installed in Windows Azure and I’ve turned off Forms based authentication in ADFS so that only certificate authentication can be used.
To do that open your ADFS snap-in on the ADFS server and click Authentication Policies in the left pane, then in the right pane under Primary Authentication | Global Settings click Edit.
Then under Extranet simply uncheck the Forms Authentication box.
Since forms based authentication is turned off in ADFS when you hit the URL you are presented with a certificate chooser. So here’s the user experience (you’ll notice in the shots below I’ve since changed the federation service name to trazurepki.cloudapp.net).
1. From an internet client the user enters the externally published URL in IE (https://mail.treyresearch.com/owa/) and hits ADFS proxy page on the WAP server and is prompted with a certificate chooser:
2. User selects certificate and enters PIN:
3. User is logged into their exchange 2010 mailbox:
Note: You can use the IE developer tools, specifically the network utility to view the redirects in IE on your way to the final destination (OWA). This can be somewhat misleading. Since we are publishing OWA via WAP, the WAP server is the only thing that is exposed to the internet and it also runs the ADFS proxy component. So when you see the OWA URL, and the ADFS URL (trazurepki.cloudapp.net in this case) they both actually resolve to the same IP…you guessed it the external interface IP of the WAP box. WAP behaves similarly to ISA/TMG in regards to reverse web proxy, the internet client only talks to the WAP box, and the WAP box proxies everything internally (to exchange in this case) via Kerberos constrained delegation. I have this entire solution published in Windows Azure, there is no real mail routing capability but it’s great to illustrate the use of exchange publication via Server 2012 R2 WAP. This is a new technology that I’m excited to see included as a server role in the Windows Server platform, add ADFS 3.0 as a hard requirement for WAP and you have a flexible and secure way to publish both claims aware and non-claims aware applications via WAP.
Server 2012 R2 adds great installation and configuration capabilities via Windows PowerShell cmdlets, WAP and ADFS 3.0 are no exception to this. In fact some WAP and ADFS 3.0 configurations can only be done via PowerShell. Additionally you can certainly go through an installation and configuration of this solution solely based on PowerShell.
Well folks once again I hope you found this post useful when developing solutions and discussing security (smart card authN), extranet access, and Exchange publication with your customers and partners. Up next I’ll cover publishing Exchange 2010 ActiveSync via Server 2012 R2 Web Application Proxy using pass-through authentication. See you next time!
Jesse “Hit-Man” Esquivel