In part one of the series on how to set up and use Web Application Proxy for publishing Exchange to the Internet, we covered Active Directory Federation Service's
role during the process and how to begin the Web Application Proxy installation. For part two, we'll complete the Web Application Proxy installation and configure Active Directory and Exchange before we publish Exchange to the Internet.
With our AD FS server ready, we're ready to configure the component that will actually sit within our perimeter network and publish Exchange to the outside world. We'll start by navigating to Add Roles and Features Wizard within Server Manager and selecting Remote Access. Choose Web Application Proxy on the Server Role Services page. After installation completes, choose Open the Web Application Proxy Wizard.
After the wizard opens, enter the internal name for the AD FS server you've just configured and the administrative credentials. Finally, select the relevant Secure Sockets Layer (SSL) certificate to use for SSL connections to the Web Application Proxy. In our case, we'll use the Wildcard certificate used earlier on our AD FS server (Figure 1).
Configure Active Directory after Web Application Proxy configuration
With the Web Application Proxy configuration complete, it's time to configure Active Directory to pre-authenticate sessions to Outlook Web App (OWA).
We'll need to perform two steps. First, we'll add the Service Principal Names that will specify that WAP is allowed to request Kerberos tokens for HTTP-based requesters. We'll also need to specify that the WAP server is allowed to authenticate requests on behalf of users for our published Exchange servers.
First, open up ADSIEDIT.MSC on an Active Directory domain control and navigate Active Directory to the WAP server using the Default naming context, and choose Properties. Once the attribute editor opens, find the servicePrincipalName attribute. This is a multi-value attribute, which means we can add multiple values to it in addition to those specified by default.
You'll need to add two lines -- one with the fully qualified domain name (FQDN) of the server and one with the NetBIOS name of the server, both of them prefixed by HTTP/. For example, this could look like HTTP/LDJ-WAP01 and LJD-WAP01.lisajanedesigns.local (Figure 2).
After saving those changes, open Active Directory Users and Computers. Find the WAP server in Active Directory and choose Properties. Select the Delegation tab followed by Trust this computer for delegation to specified services only. Select Use any authentication protocol and add your Exchange Server(s) specifying the Service Type as "http."
Configure Exchange for pre-authenticated access
With our Web Application Proxy server ready to publish and the correct configuration in Active Directory, we'll need to ensure Exchange is configured to allow pre-authenticated access using Windows Integrated Authentication for services. In our example, we'll perform pre-authentication against Outlook Web App and the Exchange Control Panel and follow it up by using pass-through authentication for other services.
For each virtual directory you'll use pre-authentication against, make sure Integrated Windows Authentication is selected. After reconfiguring the authentication mechanism used for the virtual directories, you'll need to perform iisreset /noforce against each server you havereconfigured.
Publish and test your Exchange configuration
To complete our configuration, we'll open the Remote Access Management Console to publish each service. In this example, we'll publish the services in this table.
|Outlook Web App||/OWA/||AD FS|
|Exchange Control Panel||/ECP/||AD FS|
|Exchange Web Services||/EWS/||Pass thru|
|Auto Discover||/Autodiscover/||Pass thru|
|Offline Address Book||/OAB/||Pass thru|
|Outlook Anywhere||/rpc/||Pass thru|
With the console open, navigate to Configuration > Web Application Proxy and choose Publish. For each pre-authenticated virtual directory, choose Active Directory Federation Services (AD FS) for the pre-authentication type.
Next, we'll be presented with the Relaying Party screen on the wizard. This will show our Non-Claims Application relaying party trust we created earlier. Select this and press Next. We'll be presented with options relevant to publishing the application against the backend Exchange Server itself. Make sure you choose the details carefully here because changing settings using the GUI will involve removing and recreating the settings. In our example, we can enter a friendly description for our reference, like Outlook Web App, and enter the External URL to publish OWA with a trailing slash (/).
Choose the external certificate next. In our example, this means our Wildcard certificate along with the backend server URL. Finally, enter the Service Principal Name for the Exchange server you're publishing. In our example, this is HTTP/ followed by the FQDN of the Exchange server, like: HTTP/LJD-MBX01.lisajanedesigns.local (Figure 3).
After publishing each virtual directory that requires pre-authentication, we'll use the wizard to publish our virtual directories that use pass-through authentication. Therefore, on the pre-authentication page of the wizard, we'll simply choose Pass-through to avoid pre-authentication. Then we'll enter a friendly name to describe the service we're publishing and the external and internal URLs (again with trailing slashes), and select the appropriate SSL certificate.
After publishing each virtual directory, examine the Published Web Applications section of the Remote Access Management Console. You should see the friendly name you've chosen paired with the external URL used to publish the resource.
With everything in place, test what you've put together to make sure it works correctly. Attempt to access OWA from an external computer or one that resolves the DNS names of our published Exchange resources to the WAP server. Upon accessing OWA, you should see the AD FS forms-based authentication login screen (Figure 4).
You should be able to access OWA normally after entering the correct credentials.
To make sure access on all published protocols works as expected, continue testing with tools such as the Remote Connectivity Analyzer to see that services such as Exchange Web Services, ActiveSync and Outlook Anywhere work as expected.
By using Web Application Proxy in combination with AD FS, you have a future-proof option that helps your organization. If your organization chooses to use cloud-based services such as Office 365, you can take advantage of AD FS single sign-on features to smooth the login process against on-premises and cloud services. This will ultimately offer a better end-user experience.
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.
This was first published in October 2013