You can no longer buy Forefront Threat Management Gateway, but according to Microsoft, there are a number of products
on the market that fill the void. Some organizations think they don't need protection and will publish Exchange directly to the Internet; others use their load balancer to perform this task. You can also use tools such as IIS Application Request Routing and Forefront Unified Access Gateway. And if those aren't enough, there's a new kid on the block -- Web Application Proxy, a built-in component of Windows Server 2012 R2.
With so many options, what makes Web Application Proxy (WAP) so compelling? First off, it's free with Windows Server 2012 R2, which is also true for Application Request Routing. But the added benefit of WAP is that it offers a pre-authentication option fully integrated with Active Directory Federated Services (ADFS).
You can use WAP for pre-authentication with your internal applications and to provide single sign-on to Office 365.
To use Web Application Proxy, you'll need the following components:
- One or more Windows Server 2012 R2 servers joined to the domain to use for Web Application Proxy;
- One or more Windows Server 2012 R2 servers joined to the domain to run ADFS; and
- At least one Secure Sockets Layer (SSL) certificate with the external names for Exchange and the name for the ADFS server.
Installing Web Application Proxy and publishing Exchange
To see how to use Web Application Proxy to publish Exchange to the Internet, we'll use an example organization called Lisa Jane Designs.
We've configured Exchange with the external HTTPS namespace of mail.lisajanedesigns.co.uk and used a wildcard SSL certificate called *.lisajanedesigns.co.uk. Our ADFS server will use the name sts.lisajanedesigns.co.uk, and the same wildcard SSL certificate will be used for both the ADFS server and WAP server.
Our first task for the Windows 2012 R2 servers hosting ADFS and WAP is to install the wildcard SSL certificate. Using the Microsoft Management Console certificates snap-in, we'll ensure the wildcard certificate is imported within the context of the Local Computer (Figure 1).
The certificate and associated private key should be correctly installed and issued by a valid third-party certificate authority.
Installing and configuring the ADFS role
Before installing Web Application Proxy, we'll need to set up and configure the first ADFS server for pre-authentication. Open the Add Roles and Features Wizard from Server Manager and select Active Directory Federation Services. After successfully installing ADFS, choose Configure the federation service on this server (Figure 2).
With the core installation of ADFS complete, define the configuration information to let the ADFS Configuration Wizard apply the correct configuration.
On the first page of the wizard, you have the option to choose the type of configuration to perform. In previous ADFS versions, you could create a new ADFS farm, add to an ADFS farm or create a standalone farm. A farm can have a single member; the standalone farm option has been removed in Windows Server 2012 R2. Choose Create the first federation server in a federation server farm.
On the second page of the wizard, choose Federation Service Properties, select the pre-installed SSL certificate and specify a Federation Service Name and Display Name.
The Fully Qualified Domain Name you choose can be abstract for the server name itself. It's typical to choose a name such as FS for Federation Service or STS for Security Token Service in the same way Exchange is often named Mail rather than the Exchange Server name. We've chosen sts.lisajanedesigns.co.uk for our ADFS farm's service name and will specify the company name Lisa Jane Designs as the Display Name.
Complete the Wizard, specify a domain account with no special privileges for the ADFS service to run as and recommend using the Windows Internal Database for a smaller implementation.
We'll need to register the name of the ADFS service on the LAN after installation. As the WAP server will need to resolve this on the internal LAN, we'll configure a PinPoint DNS entry in our internal DNS to specify that sts.lisajanedesigns.co.uk resolves to the internal IP of the ADFS server (Figure 3).
If the organization using the ADFS server uses Split DNS, add the record for your ADFS server in that internal DNS zone. If you don't use Split DNS or PinPoint DNS, or if you don't want clients to connect directly to the ADFS server, you can bypass this step and add the ADFS service name and IP address to the Hosts File of the WAP server.
Our final step to prep ADFS for use with WAP and Exchange publishing is to add a Relaying Party Trust. Open the ADFS Management Console, navigate to ADFS>Trust Relationships and choose Add Non-Claims-Aware Relying Party Trust.
This trust allows us to use ADFS to authenticate applications designed to use Windows Integrated Authentication. Our configuration is simple, so give it a simple name. For example, we can name it Non-Claims Application.
Next, specify an identifier for the relying party trust. This can be an arbitrary value, so continuing with our fictitious organization, we can name it https://sts.lisajanedesigns.co.uk/adfs/services/trust (Figure 4).
After completing the wizard, press Finish to open the Edit Claim Rules window. Add the rule Permit Access to All Users and press OK to complete the ADFS configuration.
This is part one in a series about using Web Application Proxy to publish Exchange to the Internet. Stay tuned for part two to continue the process, which includes installing the Web Application Proxy role, configuring Active Directory, configuring Exchange and publishing Exchange.
About the author:
Steve Goodman is an Exchange MVP and works as a technical architect for one of the U.K.'s leading Microsoft Gold partners, Phoenix IT Group. Goodman has worked in the IT industry for 14 years and has worked extensively with Microsoft Exchange since version 5.5.